🎓 A1Learner
🔍
0 of 64 lessons completed

Design an Authentication System

An authentication system is a service that checks who a user claims to be and then proves that check to other services. A login succeeds only when the presented proof matches the stored record.

The ask

A user registers with an identifier, such as an email address, and a password. The identifier names the account.

At login the user presents the identifier and the password. The system checks the pair against the stored record.

A signed-in user stays signed in across requests. Other services need a trustworthy way to accept that state.

A locked-out user needs a recovery path. That path must be as guarded as login itself.

Estimate the scale

1,000,000,000 logins happen a day.

1,000,000,000 / 86,400 = 11,574 logins per second.

Checking a password is deliberately slow work. That slowness is a cost the design pays on purpose.

Failed logins add to the same load. Attack traffic arrives on the same path as real logins.

API and data

The register operation takes an identifier and a password. The login operation takes the same pair and returns a session token.

A verify operation lets another service check a session token. A logout operation revokes one session.

Password hashing is the slow one-way turning of a password into a fixed fingerprint. The account record stores that fingerprint, never the password.

An account record holds the identifier, the password fingerprint, the account state and the recovery contacts. Session records hold their own expiry times.

High-level design

An authentication service owns registration, login, verification and recovery. Account records live in a store sharded by identifier.

A session store keeps live sessions for fast checks. Hot session reads are served from a cache.

A rate limiter guards login and recovery by account and by network address. Guessing slows down long before it can succeed.

Deep dive: password hashing

Password hashing is one-way. The fingerprint cannot be turned back into the password.

Each account mixes a random per-account value into its hash. Two accounts with the same password then store different fingerprints.

One hash takes about 100 milliseconds of CPU, by design. Slow hashing makes stolen fingerprints expensive to guess against.

11,574 x 0.1 = about 1,157 processor cores kept busy by hashing at the average login rate.

Login compares fingerprints, never passwords. A match opens a session, and a mismatch is recorded as a failed attempt.

Sessions and tokens

A session token carries 16 random bytes. Guessing a live token is far beyond reach.

The session store keeps a hash of each token, its account and its expiry. A stolen session store yields no usable tokens.

Sessions expire and can be revoked. Changing a password revokes every other session on the account.

Deep dive: single sign-on

Single sign-on is one login that unlocks many services through the central authentication service. The user signs in once, at the centre.

After login, the centre issues a signed proof for the target service. A signed proof is a statement other services can verify but cannot forge.

Each service verifies the proof with the centre's public check value. No service ever sees the user's password.

One centre means one guarded door. Recovery, rate limits and session revocation apply everywhere at once.

Attacks and recovery

Repeated failures slow further attempts for that account. A second proof, such as a code from the user's phone, guards high-risk logins.

Recovery links are single-use and short-lived. A used or expired link cannot open the account again.

A successful recovery forces a new password and revokes old sessions. The account owner is notified on a known contact.

Evaluation and trade-offs

An authentication system is a guarded door with a proof desk behind it. Hashing guards the store, and proofs guard the services.

Slow hashing protects stolen fingerprints and costs cores at login peaks. The cost is the protection, sized to stay affordable.

A central sign-on service is convenient and critical. Its outage blocks new logins, so the centre runs replicated with no single point of failure.

Cached verification is fast and slightly stale. Revocation checks shorten the staleness where the risk demands it.

Authentication scale

ItemFigure
Logins a day1,000,000,000
Login rate11,574 per second
Time for one password hashabout 100 milliseconds
Cores busy hashing on averageabout 1,157
Random bytes in a session token16

Exercise

Why is a password never stored as plain text?