Sessions: How Servers Remember Who's Logged In

A plain-English guide to session-based authentication — how a server remembers a logged-in user across stateless requests with a session ID and a server-side session store, and the trade-offs at scale.

In the backend authentication chapter we hit the core problem: HTTP is stateless, so the server forgets you after every request — yet you log in once and expect to stay logged in. Sessions are the original, still-ubiquitous answer. The idea is simple and worth understanding precisely, because every other method in this guide is, in some way, a reaction to its trade-offs.

The idea: a ticket and a memory

Session-based authentication works like a coat check. When you log in successfully, the server:

Creates a session — a record of who you are — and stores it on the server.
Generates a random session ID and gives it to you.

From then on, you send that session ID with every request. The server looks it up, finds your session, and knows it's you.

Server stores session

Get a session ID

Send ID each request

Server looks it up

The session ID is just a ticket — a random, meaningless string. All the real information (your identity, your permissions, when the session expires) lives in the server's session store, which the client never sees.

Server-side state is the defining trait

The thing to internalize: with sessions, the source of truth lives on the server. The client holds only an opaque key. This single fact drives every advantage and disadvantage that follows.

The big advantage: easy revocation

Because the server owns the session, it has total control over it. Want to log a user out everywhere, instantly? Delete their session record. The next request presents an ID that no longer exists, and they're out.

The cost: lookups and shared state

Sessions aren't free, and the price is paid at scale. Two consequences of keeping state on the server:

A lookup on every request. Each request carries an ID the server must look up in the session store before it can do anything. That's extra work on every single request.
Shared state across servers. Recall from scalability that horizontal scaling wants stateless, interchangeable servers. But sessions are state. If a user's session lives only on server A, their requests must keep going to server A — breaking free load distribution.

This tension — server-side state vs easy scaling — is exactly what motivated the token-based approach we'll meet soon.

When sessions are the right call

Despite the scaling cost, sessions remain an excellent default, especially for traditional web applications:

You get instant revocation and full server-side control.
The opaque ID leaks nothing and is simple to reason about.
For most apps, a shared session store handles scaling just fine.

Reach for sessions when control and simplicity matter and you're not at a scale where the per-request lookup hurts. The next chapter covers how that session ID actually travels between browser and server — through cookies.

Recap

Session auth stores your identity on the server and gives you an opaque session ID to present each request.
It solves HTTP's statelessness: the ID links separate requests to one logged-in user.
The defining trait is server-side state — the client holds only a meaningless key.
Its superpower is instant revocation: delete the session record and the user is logged out.
The cost is a lookup per request and shared session state, usually solved with a shared session store.

A session ID is useless unless it rides along on every request automatically. The browser mechanism that does this is the cookie. Continue to Cookies.