JSON Web Tokens (JWT): Stateless Authentication

Sessions keep your identity on the server and make you carry a meaningless ID. JSON Web Tokens (JWTs) flip that completely: the identity travels inside the token the client holds, and the server verifies it with no lookup at all. This makes JWTs stateless, which is wonderful for scaling — and creates a thorny revocation problem that you must understand before reaching for them.

The idea: a self-contained, verifiable token

A JWT is a token that contains the user's identity (their ID, maybe their roles) and is cryptographically signed by the server. When a client sends it, the server checks the signature to confirm two things: the token is genuine (the server issued it) and untampered (nothing was changed). If the signature is valid, the server trusts the contents — without any database lookup.

Contrast this directly with sessions: there, the ID was a key to look up server-side state. Here, there is no server-side state — everything needed is in the token, and the signature is what makes that safe.

Why JWTs exist: skip the lookup

The motivation is exactly the scaling cost of sessions. Sessions need a lookup on every request and a shared store across servers. JWTs remove both:

The three parts of a JWT

A JWT is three pieces joined by dots — header.payload.signature:

The signature is the heart of it. It's computed from the header, the payload, and a secret key only the server knows. Change a single character of the payload and the signature no longer matches — so the server detects any tampering instantly. That's what lets the server trust data the client has been carrying around.

Signed, not secret

A critical and frequently-misunderstood point: a standard JWT is signed, not encrypted. The payload is merely encoded, not hidden — anyone holding the token can read its contents.

The revocation problem

Here's the catch that sessions handled so easily, and JWTs handle so badly. With sessions, logging someone out instantly meant deleting the server record. But a JWT has no server record — that was the whole point. So how do you invalidate one?

The practical mitigations all chip away at it rather than fully solving it:

• Short expiry times, so a leaked token is only useful briefly (this is what motivates refresh tokens).
• A deny-list of revoked tokens — but checking it reintroduces the very per-request lookup JWTs existed to avoid.

There's no free lunch: meaningful revocation always means adding some server-side state back.

Sessions vs JWTs: choosing

This guide's two core methods trade off cleanly:

Neither is "better." Sessions suit apps that value control and easy revocation; JWTs suit stateless APIs and distributed systems where scaling and no-shared-store matter most. Many real systems combine them — a JWT for fast stateless checks, plus a touch of server state for revocation.

Recap

• A JWT is a self-contained, signed token carrying the user's identity — the server verifies it with no lookup.
• It exists to avoid the session's per-request lookup and shared store, enabling stateless scaling.
• It has three parts — header, payload, signature — and the signature proves authenticity and integrity.
• It's signed, not encrypted: the payload is readable by anyone, so never put secrets in it.
• The big downside is revocation — a valid JWT works until expiry, since there's no server record to delete.

JWTs and sessions handle users logging in. But how does an app let you log in with Google — without ever seeing your Google password? That's OAuth. Continue to OAuth Explained.