Session
Server-side state tracking a logged-in user across requests, identified by an opaque token in a cookie. The server stores the data; the token is just a key. Simpler to revoke than JWTs but needs a lookup per request.
- First-party web apps with revocable login.
- When you need to force-logout users.
- Stateless cross-domain APIs (use JWT/OAuth).
- Systems where a per-request DB hit is too costly.
Definition
A session is server-stored user state keyed by a random session ID sent in a (usually HttpOnly, Secure, SameSite) cookie. Each request looks up the ID in a store (DB/Redis) to restore identity and state.
Why it exists
HTTP is stateless; apps need continuity (logged-in user, cart). Sessions keep the secret (the ID) opaque and revocable server-side, unlike self-contained tokens.
How it works
On login, server creates a session record (user, expiry, metadata) and a random ID, sets it in a cookie. Each request, middleware reads the cookie, looks up the ID, attaches the user. Logout deletes the record. Shared session stores enable multi-instance.
Scaling limits
A lookup per request adds latency and a dependency (Redis/DB). Session stores must scale with active users and handle failover. Sticky sessions avoid shared state but complicate LB.
Cost shape
One store lookup per request + storage per active session. Redis is the usual cost; sessions expire so storage is bounded.
Alternatives
- JWT — Stateless and verifiable offline, but hard to revoke.
- Cookie + signed state — No store, but state is visible and tamper-evidence only.
Failure modes
- Session fixation (not rotating ID on login).
- Cookie not Secure/HttpOnly/SameSite.
- Shared store as a new failure point.