How Sessions Work — Cookie-Based Authentication Explained for Beginners

Where a JWT makes the client carry proof of identity, a session makes the server remember you. Login creates a record in server-side storage; the browser only ever holds a small random ID pointing at that record. Every request, the server asks “who does this ID belong to?”

The one-sentence version

A session cookie is a pointer, not the data — the real “who is this user” lives in server storage, which is exactly what makes it revocable in an instant.

What’s actually in the cookie

Open your browser’s dev tools on almost any logged-in site and you’ll see something like connect.sid=s%3AaBcD1234.... That’s it — a random string. It carries no name, no role, no permissions. All of that lives in a record on the server, keyed by this ID:

The cookie — just the session ID, marked HttpOnly (invisible to JS) and Secure (HTTPS only).
The session store — a fast key-value store (Redis is the usual choice) or a database table mapping that ID to { userId, role, createdAt, expiresAt }.

The full round trip, request by request

Login, then one authenticated request — notice the extra hop to the session store on every request. Click any arrow to jump straight to that moment.

Client

Server

Session Store

Step 1 of 9

Same first step as any login — credentials go to the server once, over HTTPS.

The superpower: logging someone out for real

Because the server actually owns the record, logging out is a single delete: DELETE session sess_abc123. The next request with that cookie finds nothing in the store and is rejected immediately — even if the cookie itself is still sitting in the browser. Compare that to a JWT, which stays valid until it naturally expires, no matter what the server wants.

Common mistake

Storing sessions in a single server’s memory (the default in many tutorials) silently breaks the moment you run more than one server instance — user A logs in on server 1, their next request hits server 2, which has never heard of them. Use a shared store like Redis once you have more than one instance.

What each flag blocks

HttpOnly — JavaScript can't read the cookie, closing off XSS theft
Secure — the cookie is only ever sent over HTTPS, never plain HTTP
SameSite=Lax/Strict — blocks the cookie from being sent on cross-site requests, limiting CSRF

What revocation unlocks

"Log out everywhere" — delete every session row for a user
Force-expire a session after a password change
Kill a session the moment suspicious activity is detected

Redis / Memcached

Common store

7–30 days, sliding

Typical TTL

1 store read / request

Lookup cost

Sessions vs. JWT, side by side

Neither is “better” — they trade the same two things in opposite directions: a session costs you a lookup on every request but buys instant, total revocation; a JWT skips the lookup for pure speed and horizontal scale, but a stolen token stays valid until it expires. Plenty of real systems use both — short JWT access tokens for API calls, backed by a session-like refresh token the server can revoke.

How sessions actually work.