JWT vs session cookies

Both are bearer tokens for proving "this request is from user X." They differ in where the truth lives and how they're carried.

Session cookies.

Client → Server: Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax
Server's DB:    sessions[abc123] = { userId: 7, expires: ... }

The cookie value is a meaningless random ID. The server looks it up in a session store (Redis, Postgres) on each request. Revoke = delete the row.

JWT.

Client receives: eyJhbGc...iJIUzI1NiJ9.eyJzdWIiOjcsImV4cCI6...}.signature
                  header         claims (incl. userId, exp)     HMAC/RSA sig

The token contains the claims (userId, expiry, scopes). The server verifies the signature with a secret/public key. No DB lookup required — the token is self-describing.

The trade-off table.

The 2026 default for browser apps: HttpOnly cookies + short-lived JWT access tokens + refresh tokens.

Login:   server sets HttpOnly cookie containing refresh token (long lifetime)
                + returns short-lived access token (15 min, JWT) — or sets it as another cookie
Request: send access token (cookie or Authorization header)
Refresh: when access token expires, hit /refresh with the refresh cookie
            → server validates refresh token (DB-backed) → issues new access token

This combines the best of both: stateless validation per request (no DB hit), revocation via the refresh side (short access tokens limit damage if a refresh is compromised).

Where to store tokens in the browser.

• HttpOnly Secure SameSite cookie — JS can't read it. XSS can't steal it. CSRF is the threat — mitigate with SameSite=Strict or Lax + a CSRF token for state-changing requests. This is the right default.
• localStorage — readable by any JS on the origin. An XSS gets the token. Avoid for auth tokens.
• In memory (variable) — survives until reload. Forces re-login each tab/refresh; some SaaS apps use this with silent SSO refresh.

The interview tell: anyone who says "I store JWT in localStorage" has not been bitten by an XSS incident.

JWT pitfalls people miss.

1. No revocation by default. Once issued, a JWT is valid until exp. If user changes password, you can't invalidate active tokens unless you keep a blocklist (which removes the stateless advantage).

1. alg: none bug. Old JWT libraries accepted {"alg":"none"} headers and skipped signature verification. Always pin the algorithm server-side: verify(token, key, { algorithms: ["HS256"] }).

1. Public-key confusion. RS256 JWTs verified with the wrong key handler — accepting "HS256" with the public key as the HMAC secret. CVE'd many libraries; use a maintained one.

1. Don't put sensitive data in claims. JWT is signed but not encrypted by default. Anyone with the token can decode it. Don't put PII or anything you wouldn't email.

1. Clock skew. Verify exp and nbf with a few seconds of tolerance.

1. Refresh token rotation. Each refresh should issue a new refresh token AND invalidate the old. Detect reuse — it usually means a stolen token.

When pure-session is fine.

Most CRUD web apps. Single domain. Few microservices. Sessions are simpler, safer, and the storage cost is trivial. Don't introduce JWTs for the resume bullet.

When JWT shines.

• Service-to-service: a microservice receiving a token from another service can verify it locally without an auth-service round-trip.
• Federated identity / SSO — OAuth's id_token is a JWT for good reason.
• Edge / serverless functions where there's no shared session store.

Senior framing. The interviewer is checking whether the candidate has gotten burned. The right answer in 2026: HttpOnly cookies are non-negotiable; whether the cookie's value is a session ID or a short-lived JWT is a backend implementation detail. Use refresh tokens for revocation. Never put tokens in localStorage. Pin the JWT algorithm.