"JWT vs session cookies"

Two ways to keep users logged in: server-side sessions with cookies versus self-contained JSON Web Tokens. How each works, revocation, size, security pitfalls, refresh tokens, storage in browsers and mobile apps, and the hybrid most large systems use.

Reading is half of it. See this used in a real interview: walk through Design Slack →

After a user logs in, every later request must prove who they are. The two common approaches are server-side sessions (a random id in a cookie, looked up on each request) and JSON Web Tokens (a signed token carrying the user's identity, verified without a lookup). Both are fine; each has costs that matter at scale. Interviewers ask about this when a design includes authentication, an API gateway or many services.

Server-side sessions

1. On login, the server creates a session record (user id, expiry, metadata) in a store and generates a long random session id.
2. The id is sent as a cookie (HttpOnly, Secure, SameSite).
3. Each request sends the cookie; the server looks up the session.

Properties:

• Instant revocation: delete the session record (logout, password change, suspicious activity).
• Small cookie: just an opaque id.
• A lookup per request: needs a fast, shared, replicated store (Redis) so any server can validate. See stateful vs stateless services.
• Natural fit for browser apps on one domain.

JSON Web Tokens

A JWT has three base64url parts: header, payload (claims such as user id, roles, expiry, issuer, audience) and a signature. Any service with the verification key can check it locally.

• No lookup: verification is a signature check, so services and gateways validate tokens without calling an auth service. Good for many services and multiple regions.
• Hard to revoke: a valid token works until it expires. Mitigate with short lifetimes (5 to 15 minutes) plus refresh tokens, or a deny list of revoked token ids (which reintroduces a lookup, but only for a small set).
• Larger: hundreds of bytes to kilobytes on every request; keep claims minimal.
• Stale claims: roles in the token do not change until it is reissued.

Use asymmetric signatures (RS256, ES256, EdDSA) so services verify with a public key and only the auth service can sign; publish keys via a JWKS endpoint and rotate them. See encryption and key management.

Common JWT mistakes

• Accepting alg: none or letting the token choose the algorithm; pin the expected algorithm.
• Not validating expiry, issuer and audience.
• Putting secrets or personal data in the payload; it is encoded, not encrypted. See hashing and encoding.
• Long-lived access tokens with no revocation path.
• Storing tokens in localStorage in browsers, where any injected script can read them.

Refresh tokens

The usual pattern pairs a short-lived access token with a long-lived refresh token:

• The access token (JWT) is sent with API requests and verified locally.
• When it expires, the client exchanges the refresh token at the auth service for a new access token.
• Refresh tokens are stored server-side (or tracked) so they can be revoked, and rotated on each use; reuse of an old refresh token signals theft and revokes the whole family.

This gives local verification on the hot path and revocation within minutes. See OAuth 2.0 and OpenID Connect.

Where to store tokens

• Browsers: prefer HttpOnly, Secure, SameSite cookies, which scripts cannot read, with CSRF protection for state-changing requests. Many teams keep a session cookie for the browser and convert it to a short-lived token at the gateway.
• Mobile apps: the platform's secure storage (Keychain, Keystore). See mobile system design.
• Service to service: short-lived tokens from the platform, or mTLS identities. See service discovery and service mesh.

Comparison

The common hybrid

Large systems often combine them: the browser holds an opaque session cookie; the API gateway validates the session (with caching) and issues a short-lived internal JWT to downstream services, which verify it locally. Users get instant logout, services get fast local checks. See API gateways.

In the interview

"Clients authenticate once and receive a short-lived signed access token plus a rotating refresh token; the gateway and services verify tokens locally with the auth service's public keys, so there is no auth call per request; revocation happens within the token lifetime, or immediately via a small deny list for compromised sessions." For browser-first products, mention HttpOnly cookies and CSRF protection. See security and auth.

Checklist

• Sessions for immediate revocation; JWTs for local verification across services.
• Short access token lifetimes plus rotating refresh tokens.
• Asymmetric signing, key rotation, strict validation of algorithm, expiry, issuer and audience.
• No secrets or personal data in token payloads.
• HttpOnly cookies in browsers, secure storage on mobile.
• Gateway hybrid: session at the edge, short internal tokens inside.