Authentication & Authorization
Who is asking, and what may they do: sessions in Redis, signed tokens, passwords, OAuth2, scopes and roles, revocation, and auth at the gateway.
An interactive System Design lesson: 25 steps, about 30 minutes, on a live simulation in your browser.
You run a shop. shopper browses and buys through the gateway to the api, which keeps sessions in sessions and users in the database. Right now the gateway checks nothing: every request passes straight to the api.
Send 100 requests a second for one second. Every one succeeds, and the p99 is 41 ms: 20 ms of work in the api plus a few milliseconds of hops. Nobody waits, because nobody is asked who they are.
What you will learn
The shop needs login
- An open shop: Identity is a dimension: once you know who is asking, limits, shards and logs can all be counted per customer instead of per fleet.
- Who you are vs what you may do
Sessions in Redis
- Login mints a session: A session cookie is a pointer: cheap to carry, and the server follows it to the truth.
- One miss, then all hits
- Redis goes down at noon: A session store is a dependency of every request: decide in advance whether its outage means logged-out users or a brief bounded fallback, never a 1 s wait on every request.
- Cold restart, short memory
Stateless tokens
- A token that carries itself: A JWT is a signed claim, not a proof: anyone can read it, only the signer can mint it, and you must verify it.
- The buyer makes herself admin: Trust no byte of a token you did not verify: signature first, then expiry, then audience, and only then the claims.
- An expired token still works
- The three checks in code
Passwords, OAuth2, scopes
- Never store a password
- Log in with someone else
- Drill: read the subject
- Scopes: lend one ability: A scope says what a token may do, not who you are: you delegate one ability at a time, and you keep each grant as small as it can be.
- Roles say who, keys serve programs: A role says who you are inside the shop; an API key lets a program act without a person. You give each the least power that works.
Refresh, revocation, MFA
- Refresh tokens and denylists: Revocation is the price of statelessness: a token that needs no lookup cannot be un-issued without a list.
- The revoked user is still in
- A token in the wrong place
- A second factor
Auth at the gateway
- Check once, at the door: Enforce auth where it is cheapest: the gateway says no before any service spends a millisecond.
- Who pays under one limit: A global limit protects the service, not the customers: the noisy client still spends the victim's share.
- One budget per identity: Fairness needs a key: a limit per identity spends each customer's flood from their own budget.
- Drill: send the token
Recap & playground
- Cheat sheet
- Playground