Sessions

A session is a server-side record — user id, creation time, last activity, device fingerprint, IP, and whatever else you need — addressed by an opaque random identifier that the client stores and returns. The identifier carries no information; it is a key into a table you control. That indirection is what gives you the properties that matter.

Because the state is yours, you can expire it (absolute and idle timeouts), revoke it (delete the row and the session is gone on the very next request), inspect it (show the user their active sessions with device and location), and change it without asking the client to do anything. None of these are available if the state lives entirely in a self-contained token, which is the central trade in JWT — What It Is and What It Costs.

The identifier itself has exactly two requirements and both are absolute: at least 128 bits of entropy from a cryptographically secure random source, and no derivation from user data. A session id built from a user id and a timestamp, or from a fast hash of predictable inputs, is guessable, and guessable sessions are silent, unlimited impersonation.

Rotation — issuing a new identifier and discarding the old one — is required at every privilege change. At login above all: if the application issued a session id to the anonymous visitor and simply attaches a user to it after login, an attacker who planted a known id in the victim's browser beforehand now holds an authenticated session. That is session fixation, and generating a fresh id at login removes it entirely. Rotate again on password change, on MFA enrolment, and on any elevation.

Expiry needs two clocks. An idle timeout ends sessions that have stopped being used, which limits the value of a token stolen from a device that has been left alone. An absolute lifetime caps the total duration regardless of activity, which limits the value of a token an attacker keeps warm by making periodic requests. Only the idle timeout is commonly implemented, and the absolute one is what prevents an indefinitely-refreshed stolen session.

Revocation is the operation that turns an incident into something with an end. The user must be able to see their sessions and end them; a password change must end all others by default; and your operations team must be able to revoke in bulk for an account, a tenant, or everyone. Test this path — bulk revocation is exactly the kind of code that is written once, never exercised, and broken when needed.

A session id in a cookie with the right attributes is the default correct answer for browser applications, because the browser stores it outside JavaScript's reach and attaches it automatically. The attributes are what make that safe, and they are covered in Cookies and Their Attributes.

A session id in a URL is a durable mistake with several independent leak paths: it lands in server access logs, in proxy logs, in browser history, in the Referer header sent to third-party sites, and in any link the user shares. Once it is in any of those, it is a valid credential in a place with no access control.

A session id in `localStorage` is readable by any JavaScript running on the origin, which means any successful XSS — including one introduced by a third-party script you did not write — reads it directly. This is the standard trade made by single-page applications that store tokens client-side, and it should be a conscious decision rather than a default: it exchanges a well-understood CSRF risk (mitigated by SameSite) for a well-understood XSS risk (mitigated by nothing you can retrofit).

The remaining consideration is where the server state lives. A shared store (Redis, a database table) gives every instance the same view and makes revocation immediate; the cost is a lookup per request and a dependency whose failure must be planned for. Sticky sessions with in-memory state avoid the lookup and break every property you wanted: no revocation, no visibility, and sessions lost on deploy.