Session management: the part of login nobody tests until it breaks

Login gets the attention; sessions get the incidents. A session is the thing that keeps a user signed in after authentication, and every property of it — lifetime, storage, rotation, revocation — is a security decision.

This article is the checklist for getting sessions right.

What a session is

After authentication, the server issues a session identifier or a token, and the client presents it on each request. The server maps it to a user and an authorization context.

Two broad designs:

• Server-side sessions: a random ID in a cookie, state stored on the server (memory, database, Redis). Revocation is immediate.
• Stateless tokens: a signed JWT the server verifies without a lookup. Scaling is easier; revocation is harder.

Most systems end up with both: a short-lived access token plus a server-side refresh session.

The cookie

If the session lives in a cookie, the flags are not optional:

For cookie-based sessions, add a CSRF token for state-changing requests. HttpOnly prevents theft, not forgery.

Lifetime: idle and absolute

Use both:

• Idle timeout — sign out after N minutes of inactivity. For consumer apps, 30 minutes to a few hours; for admin consoles, minutes.
• Absolute timeout — sign out after N hours or days regardless of activity. This bounds the damage of a stolen session.

NIST SP 800-63B ties reauthentication intervals to assurance levels; the practical rule is that higher-privilege sessions should expire sooner.

Rotation

The session identifier should change:

• At login, to prevent session fixation — an attacker who plants a session ID before login must not end up with the authenticated session.
• On privilege change, such as elevation to admin or a role change.
• Periodically, for long-lived sessions.

Rotate on the server, invalidate the old ID, and set the new cookie in the same response.

Logout has to be server-side

Deleting the cookie on the client does nothing if the session ID remains valid. A real logout:

1. Invalidates the session server-side.
2. Clears the cookie.
3. Ends related sessions if the product promises "sign out everywhere".
4. Revokes refresh tokens for the same session.

If you use stateless access tokens, keep them short-lived and revoke the refresh session; otherwise "logout" is a UI illusion.

Device lists and concurrent sessions

For products with account settings, a device list is worth the effort:

• Show each active session with device, location and last activity.
• Let the user revoke one session or all others.
• Cap concurrent sessions per user where the product allows it.

This turns "I think I was hacked" into a self-service action, and it gives support something to do besides reset passwords.

Session fixation and other traps

• Fixation: the attacker sets a session ID before login; rotation at login defeats it.
• Predictable IDs: use a CSPRNG, at least 128 bits.
• Session data in URLs: never; URLs leak through logs, history and referrers.
• Long-lived "remember me": if you offer it, make it a separate long-lived token that can be revoked, not a 30-day session cookie.
• Shared sessions across subdomains: scope cookies narrowly; a compromised subdomain should not inherit the session.

Monitoring

Log and alert on:

• Sessions created from unusual locations or devices.
• Many sessions for one user in a short window.
• Logout and revocation events.
• Failed session lookups (expired or forged IDs).

These are the signals that catch credential theft before the attacker does damage.

How identity providers fit in

An identity provider manages the session at the center: it issues tokens, tracks sessions for single logout, and can revoke them across applications. Casdoor supports session management, single logout and token revocation as part of its OIDC implementation, so applications can delegate the hard parts.

Related reading: where to store a JWT, refresh token rotation and SAML single logout.