Continuity over a protocol with no memory

How does a protocol that forgets you between every request keep you logged in?

HTTP is stateless in a strict sense: each request is self-contained, and the server is under no obligation to remember that the previous one ever happened. Two requests from the same person a second apart are, to the protocol, two unrelated events.

And yet you type a password once and stay "logged in" for a week. Something has to be bridging that gap, and it is worth asking what, precisely — because almost every attack in this area is an attack on the bridge rather than on the password.

Start from the constraint and see what it forces. If the server cannot rely on remembering the last request, then every request that needs to be attributed to you must carry its own proof. There is no third option: either the message carries the evidence, or the evidence is not there.

So what evidence? The blunt version is to resend the username and password on every single request. That is not hypothetical — HTTP Basic authentication does exactly this. It works, and it is a bad idea for reasons worth naming: the long-lived secret is transmitted constantly, it cannot be limited to part of the site, and withdrawing it means changing it everywhere it was ever used.

Which suggests the improvement. Check the password once, then issue a substitute credential that stands in for the result of that check. Now the password is exposed once instead of a thousand times, and the substitute can be short-lived, narrowly scoped, and thrown away without touching the password at all.

What should the substitute be? There are two designs, and nearly everything else in this field is a consequence of which one you picked. It can be a handle: a long random string that means nothing by itself and names a record in the server's own store, where the real facts about you live. Or it can be self-contained: a signed blob that carries the facts inside it, so any server holding the verification key can read it without a lookup.

Notice what this does to the word "stateless". The state did not disappear. It moved — out of the protocol, into the message and the store behind it. Statelessness is a property of the wire, not of the system.

Now the delivery problem. Something must attach that substitute to every request, and it has to happen without the user thinking about it. That is what cookies are for: the server sends Set-Cookie once, and thereafter the browser attaches the value automatically to every request matching the cookie's domain and path.

Sit with the word automatically, because it is doing two jobs at once. It is the entire reason a session feels continuous. It is also the reason a page you did not write can cause a request that carries your credential — the browser attaches cookies based on where a request is going, not on who caused it.

Two properties follow from all this. First, the identifier must be unguessable: it has to come from a cryptographically secure random generator with enough entropy that searching the space is hopeless, because it is a bearer credential — whoever presents it is treated as you, with no further test. Second, it needs limits the protocol will not supply by itself, which is what the cookie attributes are: Secure to keep it off plaintext connections, HttpOnly to hide it from page scripts, SameSite to restrict when it is attached cross-site, and an expiry.

One quirk that catches people out: cookie scope is not origin scope. Cookies are keyed by domain and path, and largely ignore scheme and port, so they do not obey the same-origin policy that governs the rest of the browser. The __Host- name prefix exists to pull a cookie back to a single host over HTTPS.

Three refinements.

First, "stateless" is often misheard as "keeps no state". It means the protocol imposes no requirement to keep state between requests. Session state is state; it simply lives somewhere the protocol does not know about.

Second, the handle-versus-self-contained fork matters more than it looks. A handle is trivially revocable — delete the record — but requires a lookup on every request. A self-contained token needs no lookup, which is why distributed systems like it, and is correspondingly hard to withdraw before it expires.

Third, a session credential does not prove who you are. It proves that whoever holds it was present when a password check succeeded. Identity is established once; everything afterwards is possession. That is why theft of the substitute is as good as theft of the password, and often better, since it bypasses a second factor that was only checked at login.

• Why the browser's automatic cookie attachment makes cross-site request forgery possible at all.
• What changes when the substitute is self-contained rather than a handle, especially for revocation.
• Whether binding a session to a device key removes the bearer problem entirely.

Every term the collection defines is gathered in the glossary.