Design Authentication System

Hard45 min
1 / 30
understanding6 min read

Problem Statement & Authentication Context

What a platform auth system must guarantee at Auth0/Okta scale

Problem Statement & Authentication Context

Enterprise authentication spans password login, social IdPs, SAML/OIDC federation, MFA, and API access tokens. Interviewers expect you to separate authentication (who you are) from authorization (what you may do) while proving the login path survives credential stuffing, token theft, and regional outages.

Key points

  • AuthN vs AuthZ boundaries are explicit in APIs and data stores
  • Tokens are short-lived; refresh and rotation are first-class
  • Every login event is auditable with tamper-evident logs

Deep dive

Anchor the narrative on measurable auth outcomes: login success rate, p95 token validation latency, MFA challenge completion, and mean time to revoke compromised sessions. When discussing failures, specify whether you fail closed on token verification, force step-up MFA, or drain sessions via a global revocation bus.

The core tension

Verification sits on the hot path of every authenticated request, so it must be near-stateless, cacheable, and answer in single-digit milliseconds. The credential store, by contrast, holds the most sensitive data the company owns and has to behave like a vault — encrypted at rest, tightly audited, recoverable across regions. The whole design is the act of reconciling "must be everywhere in milliseconds" with "must be a fortress." Tokens are the bridge: the identity service does the expensive proof-of-identity once at login, mints a short-lived signed token, and every downstream service then verifies that token locally — no round-trip back to auth on each call.

Failure posture, stated up front

Be explicit about which way each path fails. Token verification fails closed: a token the gateway cannot validate is rejected, never waved through on a cache miss or a key-rotation race. The login surface fails safe: it returns the same generic error and the same response time whether or not the account exists, so an attacker cannot mine it for valid usernames. And on a suspected breach the answer is never "email everyone a password reset" — it is revoke every session for the principal, kill the entire refresh-token family, and rotate signing keys, with revocation reaching edge validators within seconds.

Interview checkpoint

Open with one breath of framing: the surface (consumer, workforce, or API-first), the scale assumption (say, 500M users and 50K logins/sec at peak), and the single sentence that separates authentication from authorization. Then name your three adversaries — credential stuffing, token theft, account takeover — and the concrete defense each one forces. That earns more trust than any box-and-arrow diagram.

Key Highlights

  • AuthN vs AuthZ boundaries are explicit in APIs and data stores
  • Tokens are short-lived; refresh and rotation are first-class
  • Every login event is auditable with tamper-evident logs
Interviewer signal
Lead with Auth context metrics and failure containment, not protocol buzzwords.
Delivery tip
Do not store passwords or refresh tokens plaintext; do not skip revocation story.

Section Rescue Kit

Buzzwords to use:

Refresh rotation-1Fail-closed verify-1

Safe statements:

  • "For Problem Statement & Authentication Context, I will state assumptions before sizing stores or picking protocols."
  • "If time is short, I can defer Auth context extensions and return to core login plus verify paths."
Design Authentication System - System Design | WinJob | WinJob