Sign in

Problem Context

• Users are trying to access an existing account, protected record, workspace, invitation, checkout, subscription, saved draft, or personal data.
• The product may support password, passkey, SSO, magic link, one-time code, or multi-factor step-up authentication.
• The same surface must serve first-time visitors who need account creation, returning users who need sign in, locked or disabled accounts, and users who forgot their password.
• Security requirements may require generic error messages, throttling, risk-based step-up, protected channels, phishing-resistant authenticators, or reauthentication.
• Users may arrive from deep links and expect the product to preserve the protected destination after authentication.

Selection Rules

• Choose sign in when the user needs to start or restore an authenticated session for an existing account.
• Name the destination or service being accessed so users know why authentication is required.
• Use account creation when the user is establishing a new account, not when they are proving access to an existing one.
• Use password input for the individual secret field behavior; sign in owns the surrounding flow, routing, errors, recovery, and return destination.
• Use session timeout warning when an existing authenticated session is approaching expiry; sign in is the recovery or reauthentication destination after the boundary occurs.
• Support password managers, autofill, passkeys, and paste with standard username, current-password, one-time-code, and webauthn semantics where applicable.
• Provide forgot password, switch account, SSO, passkey, help, and create-account routes with clear priority and explanations.
• Use neutral failure copy that does not reveal whether the account exists, the password was wrong, the account is locked, or the account is disabled.
• Preserve and validate the return URL or originating task so successful authentication returns users to the protected context instead of a generic dashboard.
• Escalate to step-up authentication only when risk, policy, authenticator type, or protected action requires it.

Required States

• Initial sign-in state with service or destination context.
• Identifier entry state for email, username, phone, organization domain, or account name.
• Password, passkey, SSO, magic-link, or authenticator-choice state.
• Password-manager and autofill-ready state using credential autocomplete semantics.
• Generic failed-authentication state that preserves retry and recovery without enumeration.
• Throttled, suspicious, locked, disabled, or support-needed state with safe copy and next steps.
• Forgot-password, create-account, switch-account, and help route state.
• Step-up or one-time-code state when additional verification is required.
• Successful sign-in state that returns to the intended destination.
• Expired or invalid return-destination state with a safe fallback and explanation.

Interaction Contract

• The sign-in form identifies the protected service or destination before requesting credentials.
• Credential fields use labels and autocomplete values that let browsers, password managers, and assistive technology understand identifier, current password, passkey, and one-time-code purposes.
• Users can paste and autofill credentials unless a specific security owner approves a narrower exception with an accessible alternative.
• Failure responses do not distinguish unknown account, wrong password, locked account, disabled account, or unverified account in a way that enables enumeration.
• Retry, forgot-password, create-account, passkey, SSO, and help routes keep the return destination when policy allows.
• Successful sign in rotates or establishes the authenticated session and returns users to the protected route, invite, draft, checkout, or action they started from.
• Throttling, CAPTCHA, device challenge, or step-up checks state why more verification is needed without blaming the user or exposing sensitive status.

Implementation Checklist

• Define supported identifiers, authenticators, identity providers, passkeys, magic links, one-time codes, recovery paths, and step-up policies with security owners.
• Add username, current-password, one-time-code, and webauthn autocomplete attributes where applicable, and test browser and password-manager fill behavior.
• Preserve a validated return destination through sign in, SSO redirects, recovery, MFA, throttling, and account switching.
• Use a single generic failed-authentication message and verify HTTP status, response body, redirect behavior, error codes, timing, and analytics do not reveal account existence.
• Separate create-account, forgot-password, passwordless, SSO, passkey, and help links visually and semantically from the primary sign-in action.
• Test wrong identifier, wrong password, unknown account, locked account, disabled account, expired password, rate limit, passkey unavailable, SSO failure, MFA needed, browser Back, mobile keyboard, screen readers, high contrast, and deep-link return.

Common Generated-UI Mistakes

• Using account-specific error messages that reveal whether an identifier exists.
• Blocking paste, password managers, passkeys, or autofill by using nonstandard field names or autocomplete off.
• Sending successful users to a generic dashboard instead of the document, checkout, invite, draft, or action they requested.
• Making create account, forgot password, and sign in look like equal primary actions.
• Forcing profile setup, marketing preferences, or onboarding before completing the sign-in return path.
• Treating expired-session recovery as a brand-new sign-in without preserving private work or explaining timeout.
• Using a CAPTCHA as the only recovery from failed sign-in attempts.

Critique Questions

• What protected destination or task brought the user to sign in?
• Which identifier and authenticator options are actually supported for this account population?
• Can password managers, passkeys, one-time codes, and paste work with the fields as implemented?
• Does the failure response reveal account existence through copy, redirects, timing, status codes, URLs, or analytics?
• Where does the user land after successful sign in, SSO return, MFA, recovery, or account switch?
• Which sign-in failures require support, throttling, step-up, or password recovery rather than another retry?