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.

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.

Not specified by the original author.

TL;DR

If you use a user other than default, send AUTH username password, because AUTH with a bare password only authenticates the default user. Pass the database password on every connection (redis-cli -a, or the password field in the client config).

Fix

1. If you use a user other than default, send AUTH username password, because AUTH with a bare password only authenticates the default user. Expected: You get the expected result; the problem is gone.

When to use

• You are setting up or using this Redis Cloud feature.
• The symptom matches: NOAUTH Authentication required - password not passed.

When NOT to use

• Unrelated Redis Cloud issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Redis Cloud. Source: https://github.com/delovoymotiv/anteroslogos/blob/HEAD/docs/REDIS_SETUP.md.

Variant phrasings

NOAUTH Authentication required - password not passed

Why it happens

Commands against a Redis Cloud database return NOAUTH Authentication required even though the endpoint is reachable. Redis Cloud databases always require authentication with the database password.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/delovoymotiv/anteroslogos/blob/HEAD/docs/REDIS_SETUP.md

Source: Commands against a Redis Cloud database return NOAUTH Authentication required even though the endpoint is reachable. Redis Cloud databases always require authentication with the database password.

Verified resolution: [troubleshooting guide]: Pass the database password on every connection (redis-cli -a, or the password field in the client config). If you use a user other than default, send AUTH username password, because AUTH with a bare password only authenticates the default user. Confirm TLS is on when the subscription requires it (rediss scheme), since a plaintext connection to a TLS-only endpoint can fail at auth too.

Source URL: https://github.com/delovoymotiv/anteroslogos/blob/HEAD/docs/REDIS_SETUP.md