Login

Problem Context

• A user has submitted an account identifier, password, passkey assertion, one-time code, SSO return, or other authenticator output.
• The product must decide whether to establish a session, request another factor, delay the next attempt, lock an authenticator, or route to recovery.
• Incorrect outcome copy can expose whether an account exists, whether a password was wrong, whether an account is disabled, or whether a lockout threshold was hit.
• Security policy may require failed-attempt counters, observation windows, exponential backoff, CAPTCHA or bot checks, risk-based step-up, self-service unlock, or administrator unlock.
• Legitimate users may be typing under stress, using password managers, returning after a failed attempt, or trying to unlock without losing their original destination.

Selection Rules

• Choose login when the user has submitted credentials or an authenticator and the UI must show the result, next retry, lockout, or session-created state.
• Use sign in for the broader entry journey, destination context, method choice, SSO routing, and recovery navigation before or around login attempts.
• Use password input for the individual current-password field and visibility behavior; login owns the attempt lifecycle after submission.
• Use session timeout warning when the user is already authenticated and must extend, save, sign out, or reauthenticate before expiry.
• Use generic failed-login copy that avoids distinguishing unknown account, wrong password, locked account, disabled account, or unverified account unless a safer authenticated support path is available.
• Show remaining attempts, wait time, or unlock route only when doing so does not create a stronger enumeration or denial-of-service vector for the product.
• Clear or hide secrets after failed login, preserve the identifier when appropriate, and keep password-manager and paste behavior available.
• Treat throttling, bot checks, CAPTCHA, risk-based step-up, temporary lockout, permanent lockout, support escalation, and successful login as distinct states.
• After successful login, establish or rotate the session, reset retry counters where policy permits, remove stale warnings, and continue to the authenticated destination.
• Log and monitor failed and successful login events without exposing secrets in analytics, logs, session replay, screenshots, or user-visible URLs.

Required States

• Ready-to-submit login state with chosen identifier and authenticator route.
• Submitting or verifying state that prevents duplicate login attempts without hiding progress.
• Generic failed-login state with retry and recovery.
• Remaining-attempts warning state when policy allows visible counters.
• Throttled state with wait time or retry-after information.
• Temporary lockout state with unlock route or recovery path.
• Permanent or support-required lockout state.
• Bot check, CAPTCHA, or risk challenge state with accessible alternative.
• Successful login state with session-created and destination-continuation behavior.
• Security notice state for unusual or recent login when product policy requires surfacing it.

Interaction Contract

• Submitting credentials enters one clear verifying state and prevents duplicate submissions until the login result returns.
• Failed-login copy stays neutral across unknown account, wrong password, disabled account, unverified account, and lockout conditions unless the user has already passed a safer verification route.
• Password or secret values are cleared, hidden, or protected after failure according to policy, while non-secret identifiers can remain editable.
• Retry counters, wait time, and lockout copy match the server-side policy and cannot be faked by a client-only timer.
• Recovery, unlock, passkey, forgot-password, and support routes preserve the originating destination when policy permits.
• Successful login clears failed-attempt state, creates the authenticated session, and continues to the destination supplied by the surrounding sign-in journey.
• Bot checks or CAPTCHA do not become the only route for users who cannot complete the presented challenge.

Implementation Checklist

• Define failed-attempt thresholds, observation windows, throttle delays, lockout duration, retry reset, unlock routes, support routes, and logging with security owners.
• Map every login outcome to safe copy: success, generic failure, throttled, temporary lockout, permanent lockout, password expired, MFA needed, passkey unavailable, SSO failed, bot challenge, and recovery sent.
• Ensure response text, HTTP status, redirect path, error code, timing, analytics, and URL do not reveal account existence or exact failure reason.
• Use server-backed retry-after and lockout state rather than a client-only countdown.
• Keep password managers, paste, autofill, passkeys, and accessible alternatives working through failures, throttling, and recovery.
• Test wrong identifier, wrong password, repeated failures, success after failure, wait-period retry, lockout, unlock email, administrator unlock, CAPTCHA alternative, passkey fallback, browser Back, mobile keyboards, screen readers, high contrast, and deep-link continuation.

Common Generated-UI Mistakes

• Returning different messages for unknown account, wrong password, disabled account, or locked account.
• Silently disabling the login button after failure with no wait time or recovery path.
• Showing a client-only attempt counter that disagrees with server policy.
• Using CAPTCHA as the only route after failed attempts.
• Locking an account permanently without self-service or support escalation where policy permits recovery.
• Leaving stale failure or lockout messages after successful login.
• Logging passwords, one-time codes, passkeys, or detailed failure reasons into analytics or session replay.

Critique Questions

• Which exact login outcomes can the server return, and which are safe to distinguish in the UI?
• Can the visible attempt count, wait time, and unlock route be trusted as server-backed state?
• Does any copy, redirect, status code, error code, timing, URL, analytics event, or support route reveal account existence?
• What happens to the password or authenticator output after failed login, Back, refresh, and session timeout?
• How do legitimate users recover from throttling, lockout, inaccessible CAPTCHA, expired password, SSO failure, or passkey failure?
• Does successful login clear stale warnings and continue to the intended authenticated destination?