Skip to lesson
Exit
Deep Dive - Authentication Architecture1 / 3

2 min lesson

The reliability story

Think through this situation: "The interviewer says 'auth is on every request for a million daily users - convince me your design stays up.' What's your reliability argument in a few sentences?" Give the practical answer in plain words.

Step 1 of 3

The reliability storyauth is on every request

Because authentication sits on the hot path of a 1M-user product, its availability is the product's availability. Lead the reliability section with that and the trade-offs follow naturally.

Reliability requirements
Local verify
Stateless JWT check needs no external call - auth survives a store outage
Caching
JWKS and any authz decisions cached with sane TTLs to cut hot-path latency
Regional availability
Token issuance and JWKS served multi-region so a region loss doesn't lock users out
Graceful degradation
Decide per surface whether to fail open or closed if authz lookup is unavailable
Learn more

Full explanation

The security surface

The security surfacename the attacks, name the mitigation

Attack
Phishing
How it works
Fake login page harvests credentials
Mitigation in this design
Federate to the IdP; enforce MFA; short token lifetimes limit damage
Attack
Token theft
How it works
Token lifted from disk or memory
Mitigation in this design
OS secure storage, short access TTL, refresh rotation with reuse detection
Attack
Redirect / code interception
How it works
Attacker captures the auth code on callback
Mitigation in this design
PKCE binds code to requester; exact-match redirect URIs; state
Attack
Credential stuffing
How it works
Botnet replays leaked passwords
Mitigation in this design
Rate limit + lockout on auth endpoints; MFA; IdP federation

Walk the table out loud - naming the threat then its mitigation is the senior move.