Session Management for Web Apps: A Modern Take

What you need to know

• Server-side sessions provide instant invalidation. JWTs are stateless but cannot be invalidated before expiry without server-side state.
• Use short-lived access tokens (15 minutes) with longer refresh tokens. This limits the damage window for a compromised access token.
• JWTs in httpOnly cookies with CSRF protection are more secure than JWTs in localStorage. XSS can steal localStorage tokens; it cannot steal httpOnly cookies.
• Refresh token rotation with reuse detection is the standard for detecting stolen tokens in real time.
• Session audit logs are a compliance requirement for enterprise customers. Build them from the start.

The core argument

Session management is one of the few areas of web security where the wrong default is common and consequential. Storing JWTs in localStorage because it is simpler than cookie management exposes access tokens to XSS. Using long-lived JWTs without a blocklist means a stolen token is valid until it expires, which could be days. Implementing sessions without an audit log means that when a security incident occurs, there is no record of what sessions were active or where they came from.

The correct defaults for production web application session management in 2026: httpOnly cookies for all token storage, short-lived access tokens (15 minutes) with refresh token rotation, refresh tokens stored in httpOnly cookies or a secure database, CSRF protection via the SameSite=Strict cookie attribute or double-submit pattern, and a session audit log that records creation, refresh, and invalidation events.

Auth providers like Clerk, Auth0, and NextAuth implement most of these patterns correctly by default. For teams using a managed auth provider, the session management decisions are largely made by the provider. For teams building their own auth (usually not recommended for early-stage products), these patterns require explicit implementation and security review.

Common mistakes

1. Storing JWTs in localStorage and accepting the XSS risk. The developer experience of localStorage is better than cookies: JavaScript can read and write localStorage without server involvement. But this convenience is the security problem. Any XSS vulnerability allows an attacker to read all localStorage tokens and exfiltrate them. The correct storage for JWTs used in web applications is httpOnly cookies, which JavaScript cannot read.

1. Using long access token expiry without a refresh flow. An access token that expires in 7 days is equivalent to a password for that window. If the token is compromised, the attacker has 7 days of valid access. Short-lived access tokens (15 minutes) limit the window. Combined with refresh token rotation, the system can detect token reuse (theft indicator) and revoke the session. Long-lived access tokens without rotation are a poor security choice regardless of the storage mechanism.

1. Not implementing concurrent session control. A user who logs in on three devices has three active sessions. When the user resets their password or suspects compromise, invalidating one session does not invalidate the others. Implement a session management page where users can view and revoke active sessions. Enterprise customers will require this as part of security reviews.

1. Not testing session invalidation paths. The logout flow, the token expiry flow, and the forced invalidation flow (admin revoking a user's session) must be tested explicitly. The most common bug is a session that appears invalid in the frontend but continues to make valid API requests because the token validation logic does not check the invalidation state correctly.

1. Using the same cookie for development and production. A session cookie with SameSite=None and no Secure flag (required for localhost development) that accidentally ships to production allows the cookie to be sent over HTTP and to cross-origin requests. Production cookies must be Secure (HTTPS only) and SameSite=Strict or SameSite=Lax. Use environment-specific cookie configuration, not a single configuration that works in development but is insecure in production.

Where to start

1. Audit the current session storage and token expiry settings. Answer: where are tokens stored (localStorage vs cookie)? What is the access token expiry? Are refresh tokens implemented? Does the refresh token rotate? Are session invalidations (logout, password reset) propagated correctly to all active sessions? This audit reveals the most important session security gaps before any remediation work.

1. Migrate from localStorage to httpOnly cookies if tokens are currently in localStorage. This is the highest-impact session security improvement for applications currently storing tokens in localStorage. The migration requires changes to the token issuance (set the cookie in the HTTP response), the token reading (read from cookie in the API middleware instead of from the Authorization header), and the logout flow (clear the cookie). The client-side JavaScript that reads the token from localStorage is replaced by the cookie being sent automatically with every request.

1. Implement a session audit log table. Create a sessions table (or a session_events table) that records: session ID, user ID, created_at, last_refreshed_at, revoked_at, user_agent, IP address at creation. Update it on every session event. This table is the foundation for: showing users their active sessions, auditing suspicious access patterns, and demonstrating session management controls to enterprise security reviewers.

Related reading

• Single Sign-On for Enterprise SaaS: SAML and OIDC Compared
• Refactoring User Sessions Without Logging Anyone Out
• Right to Be Forgotten: How to Implement It Without Pain
• Server Side Request Forgery: The Quiet Killer in SaaS Integrations