Study web development for any length of time and you will run into the line "HTTP is a stateless protocol," meaning it holds no state. Yet on real websites, once you log in you're still recognized as yourself as you move from page to page. The contents of your shopping cart stay right where you left them, too.
How do you achieve something as unmistakably stateful as a logged-in session on top of HTTP, which supposedly holds no state at all? If HTTP were a clerk at a government counter, he would have hardcore amnesia. He can't even remember a visitor he met five seconds ago. I decided to sort out this slightly paradoxical-sounding story once more.
State That Lives Outside HTTP
To give away the trick: the state is managed outside HTTP. The HTTP protocol itself is not given any state. Instead, the server keeps the state on its side and only exchanges an identifier with each request. That is how pseudo-stateful behavior is produced.
Following the flow, it goes like this. First, upon a successful login, the server stores the information "this person is so-and-so" as a session. It lives in memory or a database, and the server also issues a unique session ID that points to it.
Next, the server uses response headers to have the client, the browser, store that ID. This is usually where the Cookie comes in. From then on, the client automatically attaches that ID every time it sends a request.
Finally, the server uses the arriving ID to pull out the stored session information. It then concludes, "Ah, this is a logged-in user." The clerk doesn't recognize your face, but checking the ticket number against his ledger is enough to get the job done.
Sessions and Tokens
Methods for managing login state broadly fall into two camps: the session approach and the token approach. The most traditional and common is the combination of a session and a Cookie. User information is kept on the server side in a database, Redis, or similar. The Cookie holds only the key for retrieving that information, namely the session ID.
Since the server holds the state, deleting the server-side session makes logout reliably take effect. Strike the name from the ledger and the ticket is just a scrap of paper. In exchange, you need separate storage, such as a DB or Redis, to keep the session information in.
Web APIs and SPAs also use token-based approaches such as JWT (JSON Web Token). The client holds a signed token containing the required claims, which may include user information. The server checks not only its signature, but also expiry, issuer, audience, and other relevant conditions. It is rather like verifying a signed identity card instead of consulting a ledger on every request. Revocation and current permissions may still require server-side state.
Because the server holds no state, which makes it fully stateless, it scales easily. Add as many clerks as you like; there's no ledger to share between them. That said, the challenge remains that it's hard to forcibly invalidate a token from the server side once it's been issued. There's no way for the counter to reach into a visitor's pocket and take the card back.
Why Statelessness Still Works
In short, HTTP is stateless, but applications can behave statefully. HTTP being stateless is merely a protocol-level constraint. All it says is that each request need not remember the previous one. As long as an identifier is included in the request headers, the application layer, that is, the server-side program, is entirely free to reconstruct past context.
Think of it as handing over a self-introduction card (a Cookie or token) with every request. The clerk still can't remember meeting you five seconds ago. Even so, as long as you show the card every time, the conversation gets through. That is why the exchange works even though HTTP itself has no memory.
So that's why login state can persist even though HTTP is stateless. Maintaining login state isn't achieved by extending HTTP. It rests on an application-side technique: external storage plus passing an identifier around.
Know the principle, and know how its limits are compensated for. That is the first step toward designing secure and scalable websites. When the other side can't remember you, just keep introducing yourself.