31 patterns in this category — each with its illustration, what it is, and the fields that matter when you build or review one. Part of the UX pattern catalogue; the raw, agent-readable version is ux-pattern-catalogue/auth-patterns.json.
The standard email/password login form. Single-column layout, labels above fields, email field with type="email" for mobile keyboard optimization. Show password constraints on the login page only when an error occurs — not proactively (unlike registration). Include "Forgot password?" link positioned near the password field, not buried in footer. NN/G: entering a password on mobile takes nearly twice as long as desktop, so minimize friction.
Sign in with third-party identity providers — Google, GitHub, Apple, Microsoft. Reduces registration friction: 50-80% faster than email/password (Baymard). Place social buttons above or alongside the email form with a visual divider ("or"). Use branded button styles per provider guidelines. Limit to 3-4 providers to avoid choice overload. Always support email/password as fallback.
Enterprise authentication via SAML 2.0 or OpenID Connect. The user enters their work email, the app detects the SSO-enabled domain, and redirects to their organization's identity provider (Okta, Entra ID, OneLogin). SP-initiated flow: user starts at the app. IdP-initiated flow: user starts at the IdP dashboard. Dynamically hide the password field when an SSO domain is detected for a cleaner UX.
A checkbox on the login form that extends the session beyond the browser session. When unchecked, authentication lives in a session cookie (deleted on browser close). When checked, a persistent cookie with a long-lived token keeps the user signed in for days or weeks. Protects users on shared/public computers who forget to log out. NN/G: check it by default on mobile (personal devices), uncheck by default on desktop.
Security-conscious error messages for failed login attempts. Never reveal whether the email or password is incorrect — use a generic "Invalid email or password" message to prevent account enumeration. After 3-5 failed attempts, show CAPTCHA or introduce progressive delays. After 10+ attempts, temporarily lock the account or require email verification. Log failed attempts for security monitoring.
The registration form. NN/G research: ask for the minimum — email and password should be enough. Do not include a "confirm password" field; instead, provide a show/hide toggle to verify. Single-column layout. Disclose password constraints upfront (not after submission). Social signup buttons above the form reduce friction by 50-80%. Link to login page: "Already have an account? Sign in."
Verify email ownership after registration. Send a verification email with a one-time link (expires in 24h). Show a "Check your email" page with the email address and a "Resend" button (throttled to once per 60s). Allow the user to access limited app functionality while unverified (don't block entirely). Remind them with a persistent banner until verified.
Delay non-essential data collection until after account creation. Start with only email + password, then collect profile details (name, avatar, preferences) during onboarding steps or naturally during product usage. Baymard Institute: 18% of users abandon forms that ask too much upfront. Each additional field reduces completion rate by ~5%. Collect data when the user has context for why it is needed.
Legal acceptance during registration — terms of service, privacy policy, marketing consent. GDPR requires separate, specific consent for each purpose (no pre-checked boxes for marketing). Link to full terms document (opens in new tab to preserve form state). Keep consent text concise: "I agree to the Terms of Service and Privacy Policy." Marketing consent is always optional and unchecked by default.
Connect multiple login methods to one account — e.g., a user signs up with email, then later wants to also sign in with Google. Detect duplicate emails across providers and prompt to link: "An account with this email already exists. Sign in with your password to link your Google account." Never auto-merge without explicit user confirmation. Show connected providers in account settings with ability to unlink.
Time-based One-Time Password using authenticator apps (Google Authenticator, Authy, 1Password). The gold standard for consumer MFA — phishing-resistant when combined with app verification. Setup: display a QR code encoding the shared secret, with a manual entry fallback (the secret key as text). Verify by asking the user to enter a 6-digit code from their app. Always generate backup codes during enrollment.
One-time passcode sent via SMS or email. Lower security than TOTP (vulnerable to SIM-swapping and SS7 attacks) but higher adoption due to familiarity. NIST SP 800-63B discourages SMS as a sole second factor. Use as a fallback option alongside stronger methods. Include a countdown timer for code expiry (typically 5-10 minutes). Rate-limit resend requests.
The setup flow for enabling multi-factor authentication. Present available methods (TOTP, SMS, passkeys, security keys) with brief explanations. Walk through setup step-by-step. Always generate and display backup recovery codes on completion. Do not force MFA on all users immediately — offer it during onboarding and nudge with periodic prompts. For enterprise: enforce via organization policy.
A set of 8-10 single-use codes generated during MFA enrollment. Emergency fallback when the user loses access to their authenticator app, phone, or security key. Display codes only once during setup — never retrievable again (but can regenerate a new set). Each code is 8-12 characters, alphanumeric, cryptographically random. Products typically recommend printing codes rather than storing digitally.
A login method that sends a one-time, time-limited link to the user's email. Clicking the link authenticates the user without a password. NN/G: passwordless accounts shift the security burden from the user to the email provider. Simpler than passwords but adds friction (switching to email app). Link expires in 15-30 minutes. Use for low-frequency apps where users forget passwords.
FIDO2/WebAuthn credentials stored on the user's device — biometric (fingerprint, Face ID) or device PIN. Phishing-resistant by design: credentials are bound to the domain origin. NN/G: passkeys are the most secure and convenient auth method but adoption is still growing. Support passkeys as an upgrade path alongside passwords. Synced passkeys (iCloud Keychain, Google Password Manager) work across devices.
Authentication using fingerprint, face recognition, or iris scan — typically via the device's built-in biometric sensor. On web, this is implemented through WebAuthn with platform authenticators (Touch ID, Windows Hello, Android biometric prompt). Fast and convenient for repeat access. Always provide a PIN/password fallback — biometrics can fail (wet fingers, poor lighting, injuries).
A passwordless login flow where a short numeric code (6 digits) is sent to the user's email instead of a magic link. The user enters the code in the app without switching context. Faster than magic links on desktop (no email app switching needed if the code is visible in a notification preview). Code expires in 5-10 minutes. Common in banking and fintech.
A modal dialog that warns users before their session expires due to inactivity. Show 2-5 minutes before expiry with a countdown and options to extend or sign out. Required for financial and healthcare apps (HIPAA, PCI-DSS). Do not silently expire — users lose unsaved work. The dialog should pause the countdown while the user is interacting with it.
Require the user to verify their identity again before performing sensitive actions — changing password, accessing billing, downloading data exports, modifying security settings. Even if the user is logged in (including via "Remember Me"), sensitive operations need fresh authentication. Show a compact password/biometric prompt inline or in a modal, not a full login page redirect.
A settings page showing all active sessions — device name, browser, IP address (approximate location), and last active timestamp. Users can revoke individual sessions ("Sign out this device") or all other sessions ("Sign out everywhere else"). Shows current session with a "This device" indicator. Critical for detecting unauthorized access.
Allow users to mark a device as "trusted" to skip MFA on future logins from that device. Remember the device for 30-90 days via a secure device cookie. Show a checkbox after successful MFA: "Trust this device for 30 days." Display trusted devices in security settings with the ability to revoke trust. Only offer on personal devices — never on shared/public computers.
The "Forgot password?" flow. Step 1: enter email. Step 2: receive email with reset link (expires in 1h). Step 3: enter new password. Always show the same confirmation message regardless of whether the email exists (prevent enumeration). Invalidate reset token after use. Invalidate all existing sessions on password change. NN/G: include "Forgot password?" link near the password field, not in the footer.
Multiple recovery methods beyond password reset — backup codes, recovery email, trusted device, phone number, identity verification. Display available options on the recovery page: "Try another way." Prioritize by security: backup codes > recovery email > phone > support contact. Never use security questions as a recovery method — they are easily guessable and a known anti-pattern (NIST SP 800-63B).
Temporary or permanent account lockout after repeated failed login attempts. Temporary lockout: 15-30 minutes after 10 failed attempts (prevents brute force while allowing legitimate users to retry). Permanent lockout: require email/identity verification to unlock. Always show the lockout duration and provide a path to recovery. Never reveal the exact threshold to attackers.
Changing the password from within the app (while logged in). Require current password before accepting a new one (prevents attackers with session access from locking out the real user). Show password strength meter for the new password. Do not require the user to enter the new password twice — provide a show/hide toggle instead (NN/G). Invalidate all other sessions after password change.
Inform users when rate limiting is active without revealing implementation details. Show a friendly message: "Too many attempts. Please wait a moment and try again." Display a countdown or simply ask users to wait. Never expose the exact rate limit threshold (e.g., "5 requests per minute") — this helps attackers calibrate their attacks. Log rate-limited requests for security monitoring.
Distinguish human users from bots during login, registration, and password reset. Invisible CAPTCHA (reCAPTCHA v3, Cloudflare Turnstile) scores requests without user interaction — preferred UX. Visual CAPTCHA (reCAPTCHA v2, hCaptcha) is a fallback for low-confidence scores. Never use CAPTCHA on every login — only after failed attempts or suspicious behavior. Turnstile is the most accessible modern option.
Email or push notifications for security-relevant account events — new device login, password change, MFA change, unusual location login, failed login attempts. These are mandatory notifications that cannot be unsubscribed from (unlike marketing emails). Include details: device, location, time. Provide a "This wasn't me" action link that immediately locks the account and triggers recovery.
Protect against automated attacks using stolen credentials from other breaches. Layer multiple defenses: rate limiting per IP, account lockout after failed attempts, device fingerprinting to detect automated clients, breach database checks (Have I Been Pwned API) during registration and password change. Show a warning if the chosen password has appeared in known breaches.
A dedicated security section in account settings — password change, MFA management, active sessions, trusted devices, security activity log, connected apps. Group related controls visually. Use a "danger zone" pattern for destructive actions (delete account, disable MFA) with red styling and confirmation dialogs. Link to security recommendations (enable MFA, check for breached passwords).