JWT vs Session Authentication: Which to Use and When

Session authentication is stateful. When a user logs in, the server creates a session record in a database or memory store and returns a session ID to the browser as a cookie. On every subsequent request, the browser sends that cookie and the server looks up the session ID in the store to find the associated user. The session store is the source of truth.

This model has been the standard for web applications for decades. Frameworks like Express.js with express-session, Django, Laravel, and Rails all use sessions by default. The session can hold any data — user ID, role, preferences — and that data is stored server-side. The cookie holds only the session ID, not the data itself.

JWT (JSON Web Token) authentication is stateless. When a user logs in, the server creates a signed token containing the user data (ID, role, expiry) and returns it to the client. On subsequent requests, the client sends the token in the Authorization header. The server verifies the signature cryptographically — no database lookup required. The token itself is the source of truth.

A JWT has three parts: a header specifying the algorithm, a payload containing the claims (user data), and a signature. The signature is computed using a secret key or private key. Anyone with the public key can verify the token is legitimate; only the server with the secret key can create new tokens. The payload is Base64-encoded, not encrypted — do not put sensitive data in a JWT unless you also encrypt it.

The most significant practical downside of JWTs is that you cannot revoke them before they expire. If a user logs out or an account is compromised, a session can be destroyed immediately. But a JWT continues to be valid until its expiry time because the server has no record of it. If a 24-hour JWT is stolen, the attacker has access for up to 24 hours.

The standard workaround is to use short-lived access tokens (15 minutes) paired with longer-lived refresh tokens stored in HttpOnly cookies. After 15 minutes, the client exchanges the refresh token for a new access token. If you need to revoke access immediately (account banned, password changed), you invalidate the refresh token in the database — but the access token remains valid for up to 15 minutes. For most applications, 15 minutes of residual access after revocation is an acceptable trade-off.

Both approaches have security risks that are different in nature. Session cookies should be marked HttpOnly (not accessible to JavaScript), Secure (HTTPS only), and SameSite=Strict or Lax (CSRF protection). Store sessions in a database or Redis, not in-memory, for production deployments. Rotate the session ID after login to prevent session fixation attacks.

JWTs stored in localStorage are accessible to JavaScript and vulnerable to XSS attacks. A malicious script can read the token and send it to an attacker. JWTs stored in HttpOnly cookies are not accessible to JavaScript but require CSRF protection on state-changing requests. The consensus recommendation for browser-based applications is to store JWTs in HttpOnly cookies rather than localStorage.

Session authentication requires all requests to hit the session store, which means the session store becomes a shared dependency across all server instances. For a single server this is trivial. For a horizontally scaled application with multiple instances, you need a shared session store — typically Redis. This adds infrastructure complexity but is a well-understood pattern.

JWT authentication is stateless by design: any server instance can verify a token without talking to a shared store. This makes horizontal scaling simpler, and JWTs are the natural choice for microservice architectures where multiple independent services need to authenticate the same user. A single JWT issued by the auth service can be verified by the orders service, the billing service, and the notifications service without any of them sharing session state.

Session authentication is the right choice for traditional server-rendered web applications where the frontend and backend are the same origin, for applications that require immediate revocation (banking, healthcare, enterprise security), and for teams that prefer a simpler mental model without managing token refresh logic.

Sessions also handle the logout flow cleanly: destroy the session server-side and the user is immediately and completely logged out. For consumer-facing applications where users frequently log out and back in, or where account security is critical, this immediate revocation is a meaningful advantage.

JWTs are the right choice for APIs consumed by multiple client types (web app, mobile app, third-party), for microservice architectures where multiple services need to verify the same user, and for cross-origin authentication where the API and frontend run on different domains.

JWTs are also well-suited for applications built on serverless or edge platforms that cannot maintain persistent connections to a session store. When your API needs to be stateless to scale horizontally without shared infrastructure, JWTs are the appropriate choice.

Most production JWT implementations use two tokens. The access token is short-lived (15 minutes), stateless, and sent in the Authorization header. The refresh token is long-lived (7-30 days), stored in an HttpOnly cookie, and stored in the database so it can be revoked. When the access token expires, the client sends the refresh token to a dedicated endpoint and receives a new access token.

This pattern gives you the scalability of stateless JWTs for most requests, while maintaining the ability to revoke refresh tokens immediately when needed. Revoke a refresh token and the user will be fully logged out within 15 minutes. Add the user ID to a token blocklist and you can revoke access instantly at the cost of one database lookup per request — which is essentially session authentication applied only when needed.