Session Management

How it works

After authentication succeeds, the server issues a session token, either a stateful reference (a session ID mapped to a row in a database or Redis store) or a stateless signed token such as a JWT. The client sends that token back on every request, typically in an HttpOnly, Secure, SameSite cookie. The server enforces an idle timeout (session dies after N minutes of no activity), an absolute timeout (session dies after N hours regardless of activity), and revocation, which is trivial for stateful sessions (delete the row) and requires a token blocklist or short expiry plus refresh-rotation for stateless ones.

When it matters

Session management matters from the first login flow you ship, not after. Get it wrong and you land in one of two failure modes: sessions that never expire, so a stolen laptop stays logged in indefinitely, or a stateless JWT with no revocation path, so a fired employee keeps API access until the token's natural expiry. It's the layer underneath every OIDC or SAML login; see OAuth vs OIDC vs SAML for how the initial handshake hands off into an ongoing session.

Common misconceptions

• "JWTs solve session management." JWTs solve statelessness, not revocation. You still need a short expiry plus refresh-token rotation, or a blocklist, to kill a session on demand.
• "Longer session lifetimes are just a UX convenience." Every extra hour a session stays valid past when the user needed it is an extra hour a stolen token keeps working. Weigh that against the support cost of re-login.
• "A logout button means the session is dead." A logout call that only clears the client-side cookie, without invalidating the server-side session or token, leaves it fully usable by anyone who captured it beforehand.