Sessions, Tokens, and JWT

After you authenticate once, something has to keep you logged in without re-proving your identity on every request — a session or a token. The choice between a server-side session (an opaque ID pointing to state the server holds) and a self-contained token like a JWT (claims the server signs and trusts on sight) shapes revocation, scale, and a whole class of vulnerabilities.

This topic makes the tradeoff concrete and catalogs the JWT footguns — alg:none, secrets in the payload, tokens in localStorage — that turn a login system into an open door on api.meridian.example.

Sessions vs Self-Contained Tokens

A session ID is a reference the server looks up in its own store — trivial to revoke, but it needs that shared state to scale across servers. A JWT carries signed claims the server validates without any lookup — stateless and easy to scale, but hard to revoke before it expires, because any server that trusts the signature accepts it. That is the core tradeoff: instant revocation versus stateless scale.

Anatomy of a JWT

A JWT has three parts — a header, a payload of claims, and a signature — joined by dots and base64-encoded. The signature is what makes the claims trustworthy; the payload is merely encoded, not encrypted, so anyone can read it. A JWT authenticates its claims but does not hide them, which means a secret placed in the payload is a secret published to every holder of the token.

# a JWT is three base64url parts: header.payload.signature
# anyone can read the payload without the key:
echo "$JWT" | cut -d. -f2 | base64 -d
#   {"sub":"user-91","role":"admin","exp":1735689600}

# the SIGNATURE is what must be verified — against a server-pinned algorithm and key,
# never the algorithm the token's own header claims

Decoding the middle segment shows the claims in the clear — proof that a JWT hides nothing. The only part that matters for trust is the signature, and the server must verify it against an algorithm and key it chose, never the algorithm the token itself names. That last point is the root of the most common JWT attacks.

The alg:none and Confusion Attacks

Two classic breaks come from trusting the token's own header. Accepting an alg:none token means accepting an unsigned token as valid. And an algorithm-confusion attack switches the header from RSA to HMAC and signs with the server's public key — which the server, if it trusts the header, uses as the HMAC secret. Both are defeated the same way: pin the expected algorithm and key on the verifier and reject anything else.

Revocation, Expiry, and Storage

Because a valid JWT is trusted until it expires, long-lived JWTs cannot be pulled after a compromise — the fix is short-lived access tokens paired with a revocable refresh token, or a server-side session where instant revocation matters. And where the browser keeps the token decides its exposure: an HttpOnly cookie is unreachable by JavaScript, while localStorage is readable by any XSS (Chapter 6), so one script injection exfiltrates every session.