Authentication Flows

An authentication flow maps every route by which a person proves who they are — and every route by which that proof fails and is recovered. This file maps the ROUTES; the screen-level best practices (passkey copy, 2FA hierarchy, NIST password rules) live in Privacy & Security UX. Use both together.

Auth is the flow users repeat most and forgive least. Every design decision balances four forces: security (can an attacker walk this path?) × clarity (does the user know where they are and why?) × speed (returning users want one gesture, not a ceremony) × recoverability (every locked door needs a legitimate key). A flow that maximizes any one force alone fails: max security with no recovery route creates permanent lockouts; max speed with no step-up creates account takeover.

The routes to map (all of them)

Login • signup (see Registration Flows) • logout • password reset • email verification • 2FA/MFA challenge • magic link • passkey creation and sign-in • social login (and its account-linking collisions) • locked account • session expiry and re-auth • account recovery (lost every factor). If your flow document is missing any of these, an engineer will improvise it under deadline — usually as a dead end.

Main flow with offramps

Login screen
  → Enter email → [Continue]
      ├─ unknown email → "No account found"
      │     ├─ → Create account (prefill email)      (offramp: signup)
      │     └─ → Retry (typo path: show entered email)
      └─ known → Enter password
            ├─ correct → 2FA enabled?
            │     ├─ no  → Dashboard                  (happy path)
            │     └─ yes → 2FA challenge (push/TOTP/SMS)
            │           ├─ pass → Dashboard
            │           ├─ wrong code → retry (counter) → lockout path
            │           ├─ "Try another way" → backup method list
            │           └─ no device? → Recovery flow  (offramp)
            ├─ wrong → inline error, attempt counter (n of 5)
            │     ├─ retry
            │     ├─ → Forgot password?               (offramp: reset)
            │     └─ 5th failure → Locked account
            │           → notice + unlock email / timed cooldown
            │           → Recovery flow
            └─ "Sign in another way" → passkey / magic link / social

Every error branch names its exit: retry, offramp, or recovery. A branch that ends in an error message with no arrow out is a design bug, not an edge case (see Error Flow).

Passkey-first flow shape (2026 default)

FIDO Alliance's research-backed Design Guidelines (passkeycentral.org; UX Guidelines for Passkey Creation and Sign-ins, 2023; expanded 2024) found autofill-based sign-in the most successful shape: identifier field with autocomplete="webauthn" so the browser/OS offers stored passkeys as the user focuses the field, with graceful fallback when none exists. The flow shape:

Login → Email field (passkey autofill offered by OS)
  ├─ passkey selected → biometric/PIN → Dashboard   (one gesture)
  ├─ passkey on another device → QR / hybrid cross-device ceremony
  │     └─ fails/abandoned → fallback: password or emailed code
  └─ no passkey → password path (above)
        └─ after success → "Create a passkey?" enrollment prompt
              (at moment of success, never as a login roadblock)

Show passkey wording and icons before and after the OS dialog (FIDO guidance) — the OS sheet appears and vanishes; your screens carry the narrative. Design the lost-all-devices case before shipping passkeys.

Route notes (map these branches explicitly)

Password reset: request → email sent (same message whether the account exists or not — enumeration defense) → link/code → new password → auto-login → confirm to all sessions. Branches: expired link, reused link, email never arrives ("resend" + "try another method"), user remembers password mid-flow (back to login).
Magic link: send → wait state on-screen with "enter code instead" (survives the other-device inbox case) → clicked → session. Branches: link opened in different browser, corporate scanner pre-clicks the link, expiry.
Social login: provider consent → return. The collision branch is mandatory: email already registered with password → offer linking after re-auth, never silent account duplication or silent merge.
Session expiry re-auth: preserve the user's work, re-prompt in place (modal or interstitial), return to the exact prior state. Step-up (fresh auth before payout, email change, viewing stored cards) is a branch on sensitive actions, not a global timeout.
Logout: confirm nothing, act instantly, land somewhere sensible, offer "log out of all devices" as a separate visible route.

Account recovery — the flow most teams forget to design

Recovery is what happens when every factor is gone: phone lost, email inaccessible, passkeys wiped. It is the highest-stakes route (it's the attacker's favorite door AND the legitimate user's last hope) and the one most teams leave as "contact support." Design it as a real flow: identity re-proofing steps in escalating strength (backup codes → secondary email/phone → waiting-period reset with notification to old contacts → human review), with explicit time delays and notifications to existing channels so a hijack attempt is visible and cancelable. If recovery is weaker than login, recovery IS your security level.

Common mistakes

Happy-path-only diagrams: no lockout, no lost-2FA, no recovery.
Error branches that dead-end (message with no retry/offramp arrow).
Revealing account existence inconsistently (login says "wrong password," reset says "no such account" — enumeration via mismatch).
Blocking paste/autofill anywhere in the flow (breaks managers; see Privacy & Security UX for the NIST requirement).
Treating passkey, magic link, and social as separate silo flows instead of branches of one identifier-first flow.
No mapped route back: every auth screen needs an exit to every other auth method the account supports.

Checklist

All twelve routes above mapped, or explicitly declared out of scope
Every error state has retry, offramp, or recovery arrow — no dead ends
Wrong-password branch: counter → forgot-password offramp → lockout → recovery
Passkey-first shape with fallback; cross-device and lost-device branches
2FA challenge includes "try another way" and no-device recovery
Social-login email-collision branch designed (link, don't duplicate)
Reset/verification emails: not-received, expired, and reused-link branches
Session-expiry re-auth preserves in-progress work and return state
Account recovery designed as a flow, not a support ticket
Enumeration-consistent messaging across login, signup, and reset
Step-up re-auth mapped on sensitive actions (not blanket timeouts)
Walked against Flow Design Checklists and Error Flow

Sources

FIDO Alliance — UX Guidelines for Passkey Creation and Sign-ins (2023) and Design Guidelines on Passkey Central (fidoalliance.org; passkeycentral.org) — autofill/webauthn sign-in pattern, messaging around OS dialogs, fallback guidance.
W3C — WebAuthn specification (w3.org/TR/webauthn).
NIST SP 800-63B (Rev 4, 2025) — Digital Identity Guidelines: authenticator strength, SMS-OTP restricted status, recovery.
Cross-references: Privacy & Security UX (pattern-level auth guidance), Registration Flows (signup), Error Flow (error-path method), State Flow (per-screen states).