Authentication models: authenticators, assurance, sessions, and recovery

Authentication proves control of one or more authenticators at a stated assurance level. It does not grant object permissions, and session or recovery design can be weaker than the initial ceremony.

Security invariants

• AUTHN-C1: Authentication establishes control of authenticators at an assurance level; it does not itself authorize operations on application resources.
• AUTHN-C2: Single-factor passwords are at least 15 characters under NIST SP 800-63B-4, permit long values, use blocklists and salted password hashing, and are rate-limited online.
• AUTHN-C3: AAL2 proves two distinct authentication factors and offers a phishing-resistant option; two knowledge secrets do not satisfy that rule.
• AUTHN-C4: Manual-entry OTP and out-of-band methods are not phishing-resistant because their outputs are not bound to the verifier session.
• AUTHN-C5: Origin-bound public-key authentication can be phishing-resistant; local biometric user verification need not disclose a biometric template to the verifier.
• AUTHN-C6: Session elevation, authenticator binding, and account recovery are authentication events that require explicit risk, notification, and replay controls.

Trust-boundary map

Component	Responsibility
claimant	Claimant and Browser
verifier	Authentication Verifier
password-store	Salted Password Verifier
otp-verifier	OTP or Out-of-Band Verifier
public-key-verifier	Origin-Bound Public-Key Verifier
rate-limiter	Account-Aware Rate Limiter
risk-engine	Risk and Reauthentication Policy
session-service	Session Service
recovery-service	Authenticator Recovery
attacker	Phisher or Credential Stuffer

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

password-verification — Password verification with modern controls

A long password is checked against a blocklist at enrollment, stored with a salted password hashing scheme, and protected from online guessing by throttling.

▶Walkthrough: password-verification (not found)

phishing-resistant-passkey — Origin-bound public-key authentication

A verifier-bound cryptographic ceremony resists relay to an impostor origin; local user verification does not send biometric data to the server.

▶Walkthrough: phishing-resistant-passkey (not found)

aal2-distinct-factors — AAL2 uses distinct factors

Two steps count as multi-factor only when they prove two distinct factor types; two knowledge secrets are not two factors.

▶Walkthrough: aal2-distinct-factors (not found)

otp-phishing-relay — OTP is replay-resistant but not phishing-resistant

A short-lived OTP can still be relayed by an impostor verifier because manual entry does not bind it to the legitimate verifier name.

▶Walkthrough: otp-phishing-relay (not found)

credential-stuffing-throttle — Throttle credential stuffing

Rate limiting is enforced on account and risk signals without revealing whether the identifier exists or enabling cheap lockout abuse.

▶Walkthrough: credential-stuffing-throttle (not found)

reauthentication-step-up — Reauthenticate for a sensitive event

A long-lived session is not proof of recent user presence; policy can demand a stronger or fresh ceremony before a high-risk action.

▶Walkthrough: reauthentication-step-up (not found)

recovery-is-authentication — Recovery cannot be a weaker bypass

Adding or replacing an authenticator is an authentication event with notifications, rate limits, and risk-appropriate proof.

▶Walkthrough: recovery-is-authentication (not found)

verifier-dependency-outage — Fail closed when a required verifier is unavailable

An unavailable factor verifier does not become an authentication success; recovery or fallback must satisfy an explicitly approved assurance policy.

▶Walkthrough: verifier-dependency-outage (not found)

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

[CONCEPT]oauth-oidc [CONCEPT]jwt-best-practices [CONCEPT]zero-trust [CONCEPT]authz-models

Authoritative sources

1. NIST SP 800-63B-4: Authentication and Authenticator Management
2. W3C Web Authentication Level 3
3. NIST SP 800-63C-4: Federation and Assertions