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.