Authentication and authorization
Proving who you are, and checking what you may do, on every request.
01The intuition
The problem it solves
A request arrives: "show me the file report.pdf". Two questions must be answered before any bytes go out. Who is asking? That is authentication. May that person see this file? That is authorization. They are different questions with different failure modes: an authentication bug lets a stranger pretend to be Asha; an authorization bug lets the real Asha read Ravi's file.
The naive design sends the username and password with every request and looks them up in the database each time. That is slow (a password check is deliberately slow, around 100 ms, to resist guessing), it puts the password on the wire thousands of times, and it still says nothing about what Asha may do once she is known.
Build it one piece at a time
Step 1: check the password once, hand out a session. At login, verify the password against a salted, slow hash. Then create a random session id, store it with the user id and an expiry, and give it to the client as a cookie. Every later request carries the session id, which is one fast lookup.
| Session id | User | Issued | Expires | Device |
|---|---|---|---|---|
| s_9f3a… | asha | 10:00 | in 30 days | phone |
| s_c71b… | asha | 09:12 | in 30 days | laptop |
Step 2: or sign the facts so no lookup is needed. A token such as a JWT carries "user = asha, expires = 11:00" plus a signature made with a secret the servers hold. Any server can verify it without a database. The price is that a token cannot be revoked before it expires, so keep them short-lived (15 minutes) and pair them with a longer refresh token that is checked against the database when a new short token is minted.
Step 3: let other apps act for the user (OAuth). A calendar app wants to read Asha's email contacts. It must never see her password. OAuth sends Asha to the identity provider, she approves "contacts, read only", and the app receives an access token limited to that scope. The scope is the first form of authorization: not "is this Asha" but "is this app allowed this much of Asha".
Step 4: authorization as a question to one place. For each request, after identity is known, ask a policy check: can principal P perform action A on resource R? Encode it as roles (an editor of a folder may read and write its files), as an access-control list on each object, or as relationships (Asha is a member of team X, team X owns folder Y). Put the check in one library or service so every endpoint asks the same question the same way.
Step 5: make the check fast enough to run every time. A document with ten thousand viewers cannot be checked by scanning a list per request. Cache decisions briefly, index relationships for lookup by (resource, principal), and compute group membership once per session. The check must run on every request, because the request that skips it is the one that leaks.
Why it works, with the numbers
A slow password hash is a feature: at 100 ms per guess an attacker with a stolen hash table tries 10 guesses a second per core, so a 10-character random password holds out for centuries, while a user feels the 100 ms only at login.
login: 1 slow hash ≈ 100 ms; every other request: 1 signature check ≈ 0.05 ms or 1 cache lookup ≈ 0.5 ms
The guarantee is that identity is established once per session with a strong check, and that every request is then tied to that identity and passed through the same policy. The honest failure modes: a stolen session cookie is the user until it expires, so bind sessions to devices and rotate them; a signed token cannot be recalled, so keep it short; and authorization bugs are usually a missing check, not a wrong one, which is why the check belongs in a shared layer with tests that try to read what they should not.
The trade-off you must say out loud
Stateless tokens scale without a lookup but cannot be revoked instantly; server-side sessions revoke instantly but need a fast shared store. Say the token lifetime you chose and why. The interviewer's follow-up is often "how do you log someone out everywhere" (a session store, or a per-user token version number) and "how does a service call another service as the user" (forward a scoped token, never a password).
Where it shows up in the 100 Google problems
- Build an authentication platform: the login path, sessions versus tokens, OAuth flows and two-factor, for a billion accounts.
- High-scale API gateway: token verification at the door, so services behind it only see requests with a known identity.
- Deduplicated multi-tenant file storage: the authorization check that stops shared bytes from revealing who else owns them.
- Key management service: every key use is an authorization decision with an audit line.