Design an Authentication System

Intermediate Security

The problem

Design an authentication system for a large web and mobile product: sign up, log in, stay logged in, reset a password and let other services verify the caller.

You are in a 45-minute interview. Security details matter as much as boxes and arrows.

The system serves a consumer product with tens of millions of users.

Other internal services must trust identities without calling you every time.

You are given

About 10 million users, logging in about twice a day.
80% of logins happen in a 2-hour morning window.
Password verification takes about 100 ms of CPU by design.
Mobile and web clients both use it.

What we expect from you

Drive the conversation. Ask questions before drawing anything. State your assumptions out loud so they can be corrected early.
Use numbers. Turn the givens into requests per second, storage and bandwidth. Every later choice should point back to one of them.
Start simple, then evolve. Get a working version on the board first. Add caches, sharding and queues only when a number or a requirement asks for them.
Go deep on the hard parts. For this problem the hard parts are safe password storage, session and token design, and defending against common attacks without hurting availability.
Name the trade-offs. Say what you chose, what you gave up, and what would make you change your mind.
Think about failure. Point out single points of failure and say what happens when a node, a cache or a whole zone goes down.

Scope

In scope

Signup, login, logout, password reset
Passwords, tokens and sessions
MFA and social login at a high level
Attack defences and scaling

Not required

Fine-grained authorization rules
Building a UI
Enterprise single sign-on (SAML) details

Suggested time

Clarify requirements	4 min
Estimate scale	4 min
API and data model	5 min
High-level design	7 min
Deep dive	15 min
Reliability	5 min
Trade-offs and wrap-up	5 min

What makes an answer great

Stores passwords with a slow salted hash and says why.
Uses short access tokens plus revocable refresh tokens.
Verifies tokens locally at the gateway.
Names attacks and their defences.

Key concepts

Salt

Random data added to a password before hashing, so equal passwords hash differently.

JWT

A signed token that carries claims such as user id and expiry; anyone with the public key can verify it.

Refresh token

A long-lived credential used only to get new access tokens; stored server-side so it can be revoked.

MFA

Requiring a second proof, such as a code from an app, in addition to a password.

PKCE

An extension to the OAuth code flow that stops a stolen authorization code from being used.

Credential stuffing

Trying username/password pairs leaked elsewhere, hoping people reused them.

Numbers worth remembering

10M users x 2 logins = 20M/day; peak window gives about 2,200 logins/s
Password hash target about 100 ms, so peak needs hundreds of cores
Access tokens: about 15 minutes; refresh tokens: days to weeks, rotated

Locked in so far

Decisions you confirm will collect here as you go.

Your design so far