Compare different API authentication methods.
Authentication: proving who is calling
Authentication asks who you are and authorization asks what you may do. Authentication methods differ mainly in where the identity state lives.
For this question · chapters 2 and 4 of 4
Where the session lives
- The identity badge, the proof of who is calling, still has to work on the next request. So something has to remember that badge, and the server keeps that memory in a session. The client sends Cookie: sid=7f3a, and the server looks that id up in its session store. The server finds user 124 there, so the request goes through.
- The same client sends a JWT instead. The server checks the signature, then reads the claims straight from the token: sub 124 with a 60 minute expiry. The identity state is inside the token itself, so the server skips the store check entirely. A JWT is signed, not encrypted, so don't keep real secrets inside it.
- Three servers now run behind the load balancer. Each server checks the JWT with the same key. Each server then reads the answers straight from the claims inside the token. No server reads the session store, so the servers have nothing to share. Adding a fourth server needs no shared session at all.
- Now ban user 124. Delete the row for sid=7f3a from the session store. The next request with that cookie finds no row, so the request gets 401. Revocation with a session store is one delete, and the ban works on the very next request.
- The ban is in place, and now a JWT arrives. Its signature is still valid, so server 3 answers 200 OK for a banned user. There is no session row anywhere to delete. So the token keeps working until its 60 minutes run out.
- A JWT is not more secure than a session cookie. The token skips the store lookup but is slower to revoke, so you pick one based on the use case. Sessions work well for an app with a login and a logout button. Tokens work well in microservices, where many services can verify a token with the same key, so there is no shared session store and no lookup cost.
A key names an application
- OAuth acts for a user. An API key is for an application instead, with no user involved. The app stores the key. The server stores only the key's sha256 hash, 4c7a1d, beside the key's scope and a use count of 0.
- Someone copies the api_keys table out, but every row in that copy is a hash, not a key. A request that presents 4c7a1d, one of those hashes, as its key gets a 401 from the server. A leaked key table gives no access. That protection is the reason we store only the hash.
- The server returns 200 for a GET to /invoices when key k1 is in the X-Api-Key header. The server counts that call, so k1's use count becomes 1. The server refuses a POST to /invoices with the same key and returns 403, because k1's scope is invoices:read, which only allows reading. Keys go in a header, not in the URL, because proxies and logs keep URLs.
- Key rotation needs an overlap, so you create a second key, k2, and show it once. Both keys work for a while. The app switches to k2, so the number of k1 uses in the last hour drops to 0. Retire k1 then, because that count proves nothing uses k1 anymore.
The identity badge, the proof of who is calling, still has to work on the next request. So something has to remember that badge, and the server keeps that memory in a session. The client sends Cookie: sid=7f3a, and the server looks that id up in its session store. The server finds user 124 there, so the request goes through.
Drop the expiry from 60 minutes to 15, with a refresh token rt=9c1 in the store. Revocation now means deleting that refresh token row. A banned user's access token expires within 15 minutes instead of an hour. The window, the time a banned user can still call, gets shorter but does not close.
So authentication asks who you are. Authorization asks what you may do. The methods differ mainly in where you keep the identity state. That state can be in your own store, in the token itself, or in a hashed key row.
© LearnThatStack - diagrams may not be republished without permission.
Want a quick review of the fundamentals? See the API Design cheatsheet.
74 of 92 API Design answers are in Pro.
Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.
- Full answers + code
- AI explanations, simpler or deeper
- 1,000 AI credits / month
- Cancel anytime