A JSON Web Token (JWT) is a compact, URL-safe representation of claims transmitted between parties, defined by IETF RFC 7519. A JWT consists of three Base64URL-encoded parts — header, payload, and signature — concatenated with periods. The header specifies the token type and signing algorithm; the payload carries claims (assertions about a subject such as user identity, roles, and expiry time); and the signature is computed using either a symmetric shared secret (HMAC) or an asymmetric key pair (RSA, ECDSA), allowing the receiving party to verify token integrity without a round-trip to an authorisation server. JWTs are the dominant stateless session mechanism in REST API and OAuth 2.0 / OpenID Connect identity architectures.
Content
- JWTs emerged from the web application community’s need for stateless session management as REST APIs replaced session-cookie web applications. Earlier approaches required servers to maintain session state, creating clustering and scalability problems. The JWT specification, drafted within the IETF JSON Object Signing and Encryption (JOSE) working group, was finalised as RFC 7519 in May 2015, accompanied by companion specifications for JSON Web Signature (JWS, RFC 7515), JSON Web Encryption (JWE, RFC 7516), and JSON Web Algorithms (JWA, RFC 7518). OAuth 2.0’s adoption of JWTs as access token format accelerated deployment across the industry.
- The token structure is straightforward. The header JSON object specifies “alg” (algorithm, e.g., “RS256”) and “typ” (“JWT”). The payload JSON object carries registered claim names — “iss” (issuer), “sub” (subject), “aud” (audience), “exp” (expiry epoch), “iat” (issued-at epoch) — alongside private claims carrying application-specific data such as user roles, permission scopes, or tenant identifiers. The signature is computed over the concatenated Base64URL(header) + ”.” + Base64URL(payload) string, allowing any party with the verification key to confirm integrity and authenticity without contacting the issuer. The resulting compact format (typically 200-400 bytes) is well-suited for HTTP Authorization headers and URL parameters.
- JWTs have become the de facto session credential format for microservices, single-page applications, and mobile API clients because they eliminate the session state synchronisation problem across horizontally scaled service instances. An API gateway or individual microservice can verify a JWT locally using a cached public key (retrieved from the issuer’s JWKS endpoint), making authorisation decisions without database lookups. This statelessness comes at the cost of revocability: a signed JWT remains valid until its “exp” claim is reached, so revoking a compromised token requires either short expiry windows or a token revocation list that reintroduces server-side state.
- In 2024-2025, JWT security practices have matured in response to documented attack classes: algorithm confusion attacks (exploiting “none” algorithm or RS256/HS256 confusion), claim injection via loose validation libraries, and excessively long expiry windows. Best practices now specify: rejecting unverified headers for algorithm selection, pinning expected algorithms in verifier configuration, enforcing short access token lifetimes (5-15 minutes) with refresh token rotation, and using audience (“aud”) validation to prevent token misuse across services. SD-JWT is gaining traction in digital identity wallet implementations (EU eIDAS 2.0, mDL specifications) as a privacy-preserving extension that allows holders to selectively disclose individual claims from a signed credential without revealing the full token payload.