Sessions vs JWTs

Before this

• Headers, Cookies & State — How a stateless protocol fakes memory — and where every auth bug you'll ever hit lives.
• REST API Design — Resources, not verbs — designing an interface another team can use without asking you questions.

Why this exists

HTTP is stateless, but user workflows require identity across requests. Early web architectures stored stateful session IDs on the server backed by Redis or memory, but distributed microservices struggled with centralized session lookups. Teams adopted stateless JSON Web Tokens (JWTs) to eliminate database reads on every request, inadvertently trading away instant revocation and tight security boundaries.

The mental model

A **Session** is a coat check ticket: a meaningless random token that points to your physical coat stored securely in the cloakroom. A **JWT** is a stamped passport: you carry all your credentials inside it, and any guard can verify the stamp cryptographically without checking a central registry, but if your passport is stolen, you cannot easily invalidate it until it expires.

How it works

The mechanism

In a session flow, the client sends a cookie containing `session_id=xyz`. The server queries Redis via `GET session:xyz` to retrieve identity and permissions. In a JWT flow, the client sends `Authorization: Bearer <token>`. The server parses header and payload, verifies the signature against its public key, checks that `exp > now()`, and parses the identity directly from payload claims without any network I/O.

sequenceDiagram
    autonumber
    participant Client
    participant API as API Service
    participant DB as Redis / Auth DB

    Note over Client,DB: Session Architecture
    Client->>API: GET /resource (Cookie: sid=abc)
    API->>DB: GET session:abc
    DB-->>API: { user_id: 42, role: "admin" }
    API-->>Client: 200 OK

    Note over Client,DB: Stateless JWT Architecture
    Client->>API: GET /resource (Bearer <jwt>)
    API->>API: Verify signature + exp locally
    API-->>Client: 200 OK (No DB read)

What people get wrong

JWTs are inherently more secure than session cookies.

JWT signatures guarantee data integrity, not security against theft or leakage. Storing JWTs in browser localStorage exposes them directly to Cross-Site Scripting (XSS) attacks. Session cookies using HttpOnly and SameSite flags are immune to script-based exfiltration.

JWT payload data is encrypted and hidden from users.

Standard JWTs (JWS) are merely base64URL encoded and signed, not encrypted. Anyone with access to the token string can decode the payload and read all contained claims, making it unsafe for secrets or sensitive personal identifiable information without nested encryption (JWE).

When not to use it

Monolithic architectures or applications with strict compliance requirements for immediate access revocation (e.g., banking, admin control panels).

Stateful sessions backed by Redis or an in-memory session store.

Systems passing large amounts of user claims or permissions across many internal microservices.

Opaque reference tokens at the edge gateway that resolve to internal context headers, avoiding large JWT HTTP headers.

Terms

Opaque Token

— A random string with no internal meaning or readable user data, requiring a server-side lookup to resolve identity.

Claims

— Pieces of information asserted about a user (such as user ID or role) encoded directly inside a token payload.

Revocation Denylist

— A database cache of revoked token identifiers checked during validation to reject tokens before their natural expiration.

In an interview

Connected ideas

• OAuth 2 & OpenID Connect — Delegated access done right — authorization vs authentication, and why the difference matters.
• Storing Passwords — bcrypt/argon2, salts, and why 'we hash with SHA-256' is a breach report waiting to happen.
• Caching with Redis — An in-memory store used as cache, session bag, lock, counter, and queue.

Also part of

This idea matters in more than one area — which is usually why it matters.

• HTTP Semantics