JWT Authentication: Signed Claims, Not Sessions

Why it exists

Traditional session authentication forces the server to remember every logged-in user in memory or a database like Redis. When you scale to multiple Node.js processes or containers behind a load balancer, every request must hit the same session store or share state, which adds latency and a single point of failure. JWT was designed to eliminate that server-side memory burden by moving the proof of identity into the request itself.

The mental model

Think of a JWT as a tamper-evident hall pass. A teacher signs a card that says Student: Alice, Role: Editor, Expires: 2pm. Any teacher on campus can verify the signature and trust the claims without calling the front office to ask if Alice is still enrolled. The pass is not hidden in a locked box; it is readable by anyone who holds it, but the signature proves it was not forged.

How it works

A JWT has three parts separated by dots: header, payload, and signature. The header declares the signing algorithm, typically HS256 or RS256. The payload contains claims such as user ID, roles, and expiration time. Both are Base64Url-encoded, which is not encryption. The signature is created by hashing the encoded header and payload with a secret key known only to the server, or with a private key in the case of RS256. When an Express server receives a token in the Authorization header, it recalculates the signature using the same secret. If the result matches, the server trusts the claims and proceeds without querying a session database.

When to use it

Use JWT authentication when you need stateless horizontal scaling, such as microservices or serverless functions where maintaining a central session store is impractical. It also fits when the same token must be validated by multiple independent services, like an API gateway and a backend worker, because each only needs the shared secret or public key to verify trust.

When not to use it

Do not use JWTs when you need immediate revocation, such as banning a user instantly, because the token is valid until it expires unless you maintain a deny-list, which reintroduces state. Also avoid them if the payload must stay confidential from the client, since the middle section is trivial to decode. For short-lived single-page apps, they work well; for long-lived opaque sessions, traditional server-side sessions are simpler.

One canonical example

In an Express login route, you verify credentials against a database, then call jsonwebtoken.sign with a payload containing the user ID and a fifteen-minute expiration. You return the resulting string to the client. On subsequent requests, the client sends Authorization: Bearer <token>. A middleware function verifies the signature with jwt.verify, attaches the decoded user ID to req.user, and the route handler serves the resource without ever touching Redis or a session table.