cognito NotAuthorizedException vs UserNotConfirmedException: handling

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.