# JWT vs Sessions

> Choose JWT access tokens when multiple services need to verify identity locally and a bounded delay in revocation is acceptable. Choose server-side sessions when straightforward logout, device management, and centralized authentication checks matter more than avoiding a lookup. JWT is a token format, not an alternative to the concept of a session; this comparison means self-contained JWT access tokens versus opaque session IDs backed by server-side state.

Source: https://sysround.com/compare/jwt-vs-sessions
Updated: 2026-11-05


## Side by side

| | JWT | Sessions |
|---|---|---|
| Request validation | JWT: verify signature and required claims locally | Sessions: look up an opaque session ID |
| Server-side state | No per-token record required for basic validation | Session record required |
| Revocation | Wait for expiry or add a stateful check | Invalidate record; account for caches and replicas |
| Scaling | Distributed verification; key distribution required | Shared store can serve stateless application replicas |
| Permission freshness | Embedded permissions can remain stale until expiry | Can check current policy; cached permissions can still be stale |
| Failure dependency | Known keys allow validation without issuer access | Store availability usually affects authenticated requests |
| Request size | Claims and signature increase token size | Opaque ID is usually smaller |
| Browser security | Depends on storage and transport, not JWT format | Commonly uses a protected cookie; requires CSRF defenses |

## The differences that matter

The main design difference is where request-time trust comes from. A JWT verifier trusts a signature plus validated claims such as issuer, audience, and expiration. A session verifier trusts an unguessable ID and a server-side record. Neither approach proves that the presenter is the original user if a bearer credential has been stolen.

Revocation determines how much state you actually need. A self-contained JWT generally remains usable until expiration even after the client deletes it. Immediate rejection requires something such as a denylist, a session-version lookup, or introspection. Server-side sessions make invalidation more direct, but regional replicas and validation caches can still delay enforcement.

Both approaches support horizontally scaled application servers. Sessions do not require sticky routing when replicas share a session store. JWTs remove that particular lookup, but introduce signing-key distribution, rotation, and strict validation requirements. Dynamic authorization may still require database or policy-service calls.

A common hybrid uses short-lived JWT access tokens with stateful refresh tokens. Services validate access tokens locally, while the authentication service tracks refresh-token rotation, reuse, device sessions, and revocation. Revoking refresh capability prevents renewal; it does not automatically invalidate an already issued access token.

Browser security is a separate axis. Either a JWT or an opaque session ID can travel in a Secure, HttpOnly cookie, with appropriate SameSite settings and CSRF defenses. JavaScript-readable token storage increases credential-exfiltration risk from XSS. Signed JWT payloads are normally readable, not encrypted, so avoid putting secrets in claims.

## Choose JWT when

- Several APIs need to validate a narrowly scoped access token without calling a central authentication store on every request.
- You have an explicit maximum revocation delay and can set access-token lifetimes to fit that requirement.
- Regional services must keep validating unexpired tokens during an issuer outage, using already trusted verification keys.
- Your architecture already needs issuer and audience boundaries across services, and the team can operate key rotation and strict token validation.

## Choose Sessions when

- A first-party web application needs simple login, logout, device-session listing, and selective session revocation.
- Account suspension or recovery must invalidate authentication quickly, and you can provide the required consistency for session checks.
- You want identity credentials to contain minimal information and keep session metadata under server control.
- Your application already has a reliable shared store, and avoiding a lookup is less important than keeping authentication behavior easy to reason about.

## Worked example: A ten-second account-lock requirement

Suppose a hypothetical application serves 40,000 authenticated requests per second across three regions and requires account locks to take effect within 10 seconds. A JWT with a 15-minute lifetime and no revocation check cannot meet that requirement: a token issued just before the lock could remain usable for nearly 15 minutes. Server-side sessions can meet the target if invalidation reaches every validating region within the budget and local caches do not extend it. A hybrid can also work: use JWTs, but check account or session revocation state with a bounded cache lifetime and bounded propagation delay. That restores a stateful dependency, so discuss its availability and failure policy rather than calling the design fully stateless.

## In the interview

- Start with requirements: client types, authenticated request rate, regions, maximum revocation delay, and behavior during an authentication-store outage. Do not start with 'JWT scales better.'
- Walk through login, an authenticated request, refresh, logout, and account recovery. Explain exactly when a stolen credential stops working.
- For sessions, discuss store capacity, TTLs, replication, cache invalidation, and fail-closed behavior. Explain why a shared session store avoids the need for sticky application routing.
- For JWTs, discuss algorithm allowlists, signature verification, issuer and audience validation, expiration, clock-skew allowance, and signing-key rotation. Expect questions about unknown key IDs and an unavailable key endpoint.
- Separate authentication from authorization. A valid credential does not prove that a user still has access to a document or account; explain where current permissions are checked.

## Common mistakes

- Treating JWTs and cookies as competing options. JWT describes a token format; a cookie describes one way to store and transmit a credential.
- Claiming JWT logout is immediate after deleting the token or revoking its refresh token. A copied access token can remain valid until expiry unless verifiers check revocation state.
- Claiming sessions cannot scale without sticky routing. Shared, partitioned session storage allows application replicas to remain stateless between requests.
- Treating a valid signature as sufficient validation, or assuming signed claims are encrypted. Verifiers must also enforce the intended algorithm, issuer, audience, and time constraints.

## Interview questions where it comes up

- [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): The choice directly affects login, refresh, device-session management, account recovery, and how quickly compromised credentials can be revoked.
- [Design Google Docs](https://sysround.com/questions/design-google-docs): Long-lived connections require an explicit policy for credential expiry, reauthentication, and removing access when document permissions change.
- [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Offline clients and changing shared-folder permissions require separating credential validity from current authorization on each sync operation.

## FAQ

### Is JWT more secure than session authentication?

Neither is inherently more secure. Security depends on credential storage, transport, validation, lifetime, revocation, and recovery flows. Server-side sessions often make centralized revocation simpler, while JWTs require particular care around claim validation and stale credentials.

### Can JWTs be stored in cookies?

Yes. A JWT can be sent in a Secure, HttpOnly cookie, just like an opaque session ID. Cookie-based authentication still needs appropriate CSRF protection, and HttpOnly limits token reads by JavaScript but does not make an application immune to XSS.

### Are JWTs better than sessions for microservices?

JWT access tokens can let services verify identity locally, reducing dependence on a central session lookup. That is useful when token scope, audience, and lifetime match the service boundaries. Sessions can also work behind a gateway, and either approach may still need current authorization checks.

## Related concepts

- [JWT](https://sysround.com/concepts/jwt)
- [OAuth 2.0](https://sysround.com/concepts/oauth)
- [Stateless services](https://sysround.com/concepts/stateless-services)
- [Access control and RBAC](https://sysround.com/concepts/access-control)
- [Cache invalidation](https://sysround.com/concepts/cache-invalidation)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.