JWT put claims in a signed token, so a server verifies with no session store

When a user logs in, the server usually mints a session id and stores the user in a table; each request then hits that table. That works on one box, but a fleet of stateless API servers cannot share an in-memory table without a cache or sticky sessions.

JWT moves the user's claims into the token itself. The token is a compact, URL-safe JSON payload, signed so it cannot be forged. The server checks the signature and reads the claims straight out of the token.

The result is stateless authentication: any server that knows the public key can verify any user with no shared session store. The claims and the proof travel together, which is why JWT became the default for API auth and single sign-on.

Put the claims in the token; the signature is the proof.

Because the token is self-contained, a verifier needs no database call, so the request path stays flat and fast.

The signature, not the session, is the trust anchor, so any stateless server with the key can verify any token.

Its three-part header.payload.signature structure is simple for every language in a web ecosystem to implement.

It composes with OAuth and OpenID Connect, so the same token works across many services and products.

If the proof travels with the claim, you can verify anywhere and scale the verifier horizontally, because identity becomes self-contained rather than a lookup.

JWT was standardized as RFC 7519 in May 2015, complete with a JWS/JWE family. It became the default for single-page-app auth, API gateways and microservices. Its known weaknesses are revocation (a token cannot be invalidated before expiry without a denylist) and algorithm-confusion bugs, plus size overhead versus opaque sessions.