Sessions, cookies, and tokens
How a stateless protocol manages to remember you at all.
Recall from the first course that every request starts from nothing. So how does a site know you are still logged in on page seven? Because something small is attached to every single request that identifies you, and that something is almost always a cookie.
- Prove it once
You send your password. The server checks it. - Get a token
The server sends back a long unguessable string. - Browser stores it
A cookie is kept and attached automatically to every later request. - Server recognises it
Each request arrives with the token and is identified.
There are two flavours of that token. A session id is meaningless on its own, just a ticket number the server looks up in its own records. A signed token (a JWT is the common one) contains the information itself, cryptographically signed so it cannot be tampered with, and needs no lookup.
Session id
- Server looks it up every request
- Logging out is instant and reliable
- Requires shared storage across servers
Signed token
- No lookup needed, scales easily
- Cannot be revoked before it expires
- Anyone holding it can read what is inside
What to remember
- A cookie carries an identifier on every request, which is how memory happens.
- Session ids are looked up; signed tokens carry their own data.
- Signed tokens are hard to revoke, so they must be short-lived.
Terms in this lesson
Show field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.