Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder

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.

Advertisement (In-Content)

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.