JWT (JSON Web Token)
A signed, self-contained token carrying identity claims — verifiable by any service without a database call, and revocable by none of them.
Last reviewed: July 25, 2026
What is a JWT?
A JSON Web Token packs claims (subject, issuer, expiry, roles) into a base64-encoded, cryptographically signed payload: header.payload.signature. Any service holding the public key verifies authenticity locally — no session-store lookup — which is why JWTs power OAuth/OIDC flows and stateless API auth everywhere. The signature guarantee is integrity, not secrecy: payloads are readable by anyone; JWTs are tamper-evident postcards, not sealed envelopes.
The trade everyone signs, few read
Statelessness cuts both ways. No lookup per request is the scaling win; no revocation is the price. A stolen token is valid until expiry — logout, password change, and account suspension do not invalidate already-issued JWTs. The standard architecture accepts this deliberately: short-lived access tokens (5–15 min) + long-lived revocable refresh tokens, bounding stolen-token damage to minutes. Long-lived access JWTs recreate sessions minus the ability to end them — the worst of both designs.
Verification is a checklist, not a step
Real-world JWT breaches are almost all verification bugs, and the classics still circulate: accepting alg: none; algorithm-confusion attacks (validating an HMAC token against an RSA public key); skipping audience/issuer checks so a token minted for one service replays against another; trusting expiry client-side only. Use a maintained library, pin expected algorithms, validate iss, aud, exp — every time, every service.
What people get wrong
- Sensitive data in claims — payloads are public; PII in a JWT is PII in every log that captures a header.
- localStorage as token home: one XSS equals token theft; httpOnly cookies or in-memory storage narrow the blast radius.
- JWTs where sessions belong — a monolith with one database gains nothing from statelessness and loses revocation for free.
Primary source: RFC 7519 — JSON Web Token
JWTs and Statelessness in Distributed Systems
The stateless nature of JWTs makes them particularly well suited to microservices architectures, where a request might pass through several independent services, each of which can verify the token’s signature locally using a shared public key or secret, without needing to make a network call back to a central authentication service to check session validity. This avoids introducing the authentication server as a bottleneck or single point of failure for every request across a distributed system, at the cost of the tradeoffs inherent to any stateless token — namely, that revoking access before a token’s natural expiration requires additional infrastructure, since there’s no central session store to simply delete an entry from.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.