Why You Stay Logged In — Cookies, Sessions, and Tokens

Once you log in to a website, you stay logged in as you move from page to page. The items in your cart are still there, and your name stays at the top of the screen. It may be so obvious that you’ve never questioned it. But this doesn’t actually happen on its own.

The answers to questions like “Why do I keep getting logged out?”, “How does staying logged in work?”, and “Why can’t I log in when I block cookies?” are all tied together in one bundle. In this post, I’ll unpack how a logged-in state is kept, through three words: cookies, sessions, and tokens. There’s no code.

The web doesn’t even remember someone it just saw #

Let’s start with a surprising fact: the web is built so that, by default, it doesn’t remember users.

A web browser and a server talk through an agreement called HTTP. This conversation has a peculiar trait: it treats each request as separate from the others. Even a server that just showed you a screen treats you like a first-time visitor the moment the next request comes in. By default, it doesn’t remember what happened just before.

This trait is what lets the web work simply and robustly, but left as is, it creates a problem. Even if you enter your ID and password correctly on the login screen, the moment you move to the next screen the server forgets who you were. If you had to log in again every time you changed pages, no one would use a service like that. So you need a way to carry the fact that “this is the person who just logged in” somewhere along with you.

A cookie is a small note the browser keeps #

The first tool for solving this problem is the cookie. Think of a cookie as a small note the server hands to the browser.

When you log in successfully, the server hands the browser a note that carries a mark saying “this person has been verified.” The browser keeps this note and then automatically presents it along with every request to the same site. The server sees the note attached to the incoming request and recognizes you as the person from before. The reason you stay logged in as you move between pages is that this note follows along with every request.

It’s a lot like the wristband they put on you at the entrance to an amusement park. Once your entry is verified and you’re wearing the band, you don’t have to buy a ticket again for each ride inside — just showing your wrist is enough. This is also why you can’t log in if you block cookies. It’s like refusing the wristband, so the server has no way to recognize who you are each time.

With a session, the server holds the information and hands you only a tag #

Depending on what you put in the cookie, the approach splits. One of them is the session.

In the session approach, the server keeps the important information itself. It puts who logged in and what permissions they have into storage on the server side, and the cookie it hands the user carries only a tag pointing to that storage. It’s like checking your coat at a clothing shop and getting only a number tag. The shop keeps the actual information that corresponds to the coat, and the customer carries only the tag, presenting it on the way out. This tag is called a session ID.

The advantage of this approach is that it’s easy to control. Since the server holds the information, if a problem comes up it can invalidate that tag and log the user out right away. In exchange, as the number of users grows, so does the amount of information the server has to keep.

With a token, the user carries the information around #

Another approach is the token. Unlike a session, instead of the server holding the information, it sends everything along with the user.

When you log in successfully, the server issues a slip that carries the content “this is who the person is and what they can do.” This slip is the token. From then on, the user presents this slip with every request, and the server only has to check that the slip is genuine and not forged. Because the customer carries the information themselves, the server doesn’t have to keep separate storage.

A natural worry comes up here. If it’s a slip the user carries around, couldn’t they alter its contents at will? That’s why a token includes a seal that detects forgery. Change the contents even slightly and the seal breaks, so the server immediately notices it’s fake. A commonly used token format is called JWT, but you don’t need to memorize the name. It’s enough to remember the idea that the information is carried by the user in a verifiable form.

The token approach scales well because the server doesn’t have to remember each user one by one. In exchange, a slip once issued cannot easily be revoked before it expires, so controls like a forced logout take more effort than with sessions. Which to use, a session or a token, is decided by weighing these trade-offs.

So this is what explains those everyday things #

Once you know this principle, a number of everyday experiences fall into place at once.

• The “remember me” checkbox. Check it and the cookie or token’s validity period is set long, so you stay logged in for a while even after closing and reopening the browser. Leave it unchecked and you usually stay logged in for a shorter time before it lapses.
• Getting logged out suddenly. Either the validity period passed and the note or slip expired, or the server invalidated that information for security reasons.
• Warnings on shared computers. If the cookie stays behind, the next person can use that note as is. That’s why logging out matters on shared computers.
• Security and HTTPS. A cookie or token is essentially a pass. If someone intercepts it in transit, they can pretend to be you. That’s exactly why HTTPS, which encrypts the communication, matters.

Why this makes work easier for non-developers #

• You can answer login questions accurately. When you get a report that someone keeps getting logged out, you can think through the places to check together, like the validity period or cookie settings.
• You can report bugs well. Sharing which browser it happened in, whether “remember me” was on, and when it starts dropping makes the cause far faster to find.
• You develop a sense for privacy. Once you know that cookies and tokens are passes, you naturally understand why they shouldn’t be shared carelessly, and why HTTPS and logging out are emphasized.

Wrapping up #

Behind the ordinary experience of staying logged in once you sign in, there’s a mechanism that makes a web that can’t remember users remember them after all. We looked at the cookie the browser carries automatically, the session where the server keeps the information and hands over only a tag, and the token where the user carries the information in a verifiable form.

Once you remember that these mechanisms are, in the end, passes, the conversation about login and security gets a lot clearer. If you’re curious about the bigger picture of how a browser and server exchange requests and responses, read What Is an API; if you want to know how the attacks that target this information have evolved, read A History of Computer Viruses and Ransomware.