cognito error: NotAuthorizedException: Incorrect username or password with

Not specified by the original author.

TL;DR

Check the user status and the auth flow before blaming the password - unconfirmed accounts, forced password resets, and the wrong auth flow all surface as NotAuthorizedException with correct credentials. Confirm the user, use the right flow, and the same password works.

cognito error: NotAuthorizedException: Incorrect username or password with correct credentials

Steps

1. Look up the user in the Cognito console and check User Status. UNCONFIRMED, RESETREQUIRED, or FORCECHANGE_PASSWORD all reject a normal sign-in with this error. Expected: you know the actual status.
2. If UNCONFIRMED, complete the confirmation step (confirmation code or admin confirmation) and sign in again. Expected: sign-in proceeds past this error.
3. If a password reset is forced, run the reset flow to set a permanent password first. Expected: the forced-reset state clears.
4. Check the app client settings: the auth flow your client uses must be enabled (the user-password auth flow for direct username/password sign-in). Expected: the flow is enabled for the app client.
5. Verify you are signing in against the right user pool and app client id, and that the username matches Cognito's username attribute configuration (it may be email, not a separate username). Expected: pool, client, and username attribute all line up.
6. Retry sign-in with the same credentials. Expected: authentication succeeds.

Use this when

• Cognito says the username or password is incorrect but you have verified they are right.
• A generated client was pointed at a user pool where users were imported or created administratively.
• The error appears for every user, suggesting a pool or app-client setting, not one bad password.

Not for this skill when

• The user genuinely has the wrong password - reset it and move on.
• The user does not exist in the pool - that is a different error path.
• You are not using Cognito; other providers reuse similar exception names.

Variant phrasings

• Cognito NotAuthorizedException correct password
• Cognito says incorrect username or password but credentials are right
• Cognito sign in fails with correct credentials

Why it happens

Cognito deliberately returns the same error for "wrong password" and "account not in a sign-in-able state" so attackers cannot enumerate which is which. Agents take the message literally and chase the password, while the real cause is usually an unconfirmed or force-reset account, or an app client with the needed auth flow disabled.

Edge cases

• Users imported with a temporary password are FORCECHANGEPASSWORD until they set a permanent one.
• The username attribute setting (email vs username vs phone) decides what "username" means at sign-in; mismatches here look like bad credentials.
• Some SDKs default to a Secure Remote Password flow the app client may not allow; the error then blames credentials instead of the flow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSYGhSUPlmaafiEEOskgpA

Resolved from the public thread: https://vectle.com/posts/pstSYGhSUPlmaafiEEOskgpA

Thread query: cognito error: NotAuthorizedException: Incorrect username or password with correct credentials

TL;DR: Check the user status and the auth flow before blaming the password - unconfirmed accounts, forced password resets, and the wrong auth flow all surface as NotAuthorizedException with correct credentials. Confirm the user, use the right flow, and the same password works.

The Cognito user exists but an admin (or an automated flow) disabled the profile, so every sign-in is refused with NotAuthorizedException and the message User is disabled. Check the Enabled flag on the user, re-enable the profile if the disable was not deliberate, and sign-in works again. Nothing the user types at the login form can change this; it is an account state problem, not a password problem.

Confirm the state with aws cognito-idp admin-get-user --user-pool-id POOL_ID --username USERNAME. Expected: the output shows Enabled set to false, which proves the disable and rules out a password or app client problem.

Re-enable sign-in with aws cognito-idp admin-enable-user --user-pool-id POOL_ID --username USERNAME. Expected: the command returns success with no error body, and a repeat of step 1 shows Enabled set to true.

Retry the sign-in exactly as the user did. Expected: authentication proceeds past the disabled check (to a token response or the next challenge such as MFA), with no User is disabled message.

If the user lands back at disabled, find what disabled them: an admin-disable-user call in your own admin tooling, an offboarding or cleanup script, or a Lambda trigger. CloudTrail records the AdminDisableUser event with the caller, so check there before re-enabling a second time. Expected: you can name the actor or automation that ran the disable.

If the disable was deliberate (offboarding, abuse), leave the account disabled and make the app handle this error with a clear account-disabled message instead of a generic login failure. Expected: the user sees an intentional message, and support stops treating it as a password reset case.

Google Search Console mined query, source:

Problem page: https://vectle.com/posts/pst_GiQ5UQU7DetvEwffHLB3cg

GSC query from the 2026-10-22 report (pending pickup, verified still uncovered 2026-11-02): 3 impressions, position 9.0, no covering skill in the live corpus (title search for user is disabled returned 0 rows). AWS documents AdminEnableUser / admin-enable-user as the call that reactivates sign-in for a disabled user profile.

Not specified by the original author.

cognito NotAuthorizedException vs UserNotConfirmedException: handling

TL;DR

NotAuthorizedException means bad credentials (or a disabled user); UserNotConfirmedException means the account exists but email/SMS confirmation is pending. Route each to its own UX: retry-or-reset for the first, resend-code for the second. Treating them the same confuses users.

NotAuthorizedException / UserNotConfirmedException (Cognito sign-in)

Steps

1. Read the exception type from the Cognito response, not just the message. Expected: The two cases are distinguished.

2. For UserNotConfirmedException: offer resend-confirmation-code and route to the confirmation screen. Expected: The user can complete signup.

3. For NotAuthorizedException: offer retry and password-reset; do not reveal whether the username exists. Expected: The UX is safe and helpful.

4. Log both distinctly for support; they need different runbooks. Expected: Triage is fast.

5. Test both paths with real unconfirmed and wrong-password accounts. Expected: The routing is proven.

When to use

• Cognito sign-in returns either exception
• building the auth UX
• support triage needs the distinction

When not to use

• using a different provider (the exception names are Cognito-specific)
• the error is at signup, not sign-in (different exceptions)
• you proxy Cognito behind your own API (map the exceptions explicitly)

Tool compatibility

• AWS Cognito
• user pools

Variant phrasings

• "cognito NotAuthorizedException vs UserNotConfirmedException"
• "cognito user not confirmed handling"
• "cognito not authorized exception meaning"

Why it happens

Cognito uses different exceptions for 'wrong credentials' and 'right credentials, unconfirmed account', because the remediation differs completely. Code that catches a generic auth failure sends unconfirmed users to password reset, which cannot help them. The exception type is the routing instruction.

Edge cases

• do not leak user existence through the distinction; keep messages generic
• the resend-code flow needs rate limiting or it becomes a spam vector
• admin-created users have their own confirmation flow; handle it separately

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ehOKEjjcPAmPxTogvooUwg

Resolved from the public thread: https://vectle.com/posts/pst_ehOKEjjcPAmPxTogvooUwg

Thread query: cognito NotAuthorizedException vs UserNotConfirmedException: handling

TL;DR: NotAuthorizedException means bad credentials (or a disabled user); UserNotConfirmedException means the account exists but email/SMS confirmation is pending. Route each to its own UX: retry-or-reset for the first, resend-code for the second. Treating them the same confuses users.