JSON Web Token (JWT)

A JSON Web Token (JWT) is a compact, URL-safe, cryptographically signed data structure used to transmit claims — pieces of information about a user or system — between parties in a way that the receiving party can verify hasn’t been tampered with, without necessarily needing to contact the issuer to check.

Structure

A JWT consists of three base64url-encoded parts separated by periods: a header (specifying the signing algorithm used), a payload (the actual claims, such as a user ID, an expiration time, and any other application-specific data), and a signature (computed over the header and payload using a secret key or private key, which is what allows the token to be verified as authentic and unmodified). Because the header and payload are only encoded, not encrypted, anyone who has a JWT can read its contents — JWTs are not a mechanism for keeping data confidential, only for proving that data hasn’t been altered since it was signed.

Why They’re Widely Used

JWTs enable stateless authentication: a server can verify a JWT’s signature using a key it already has, without needing to look up a session in a database, which makes JWTs well suited to distributed systems and microservices architectures where checking a centralized session store on every request would add latency and a scaling bottleneck. This is also why JWTs are central to protocols like OAuth 2.0 and OpenID Connect, where an identity provider issues a signed token that a resource server can independently verify.

Practical Security Considerations

Because a valid JWT is trusted until its stated expiration time, and there’s no built-in way to invalidate one early without additional infrastructure (like a revocation list), JWTs are typically issued with short expiration times and paired with a separate refresh token mechanism for obtaining new ones — a design that limits how long a stolen JWT remains useful to an attacker, since it will expire on its own within a short window even if it’s never explicitly revoked.

JWTs and Token Introspection as an Alternative

For scenarios where the stateless, hard-to-revoke nature of JWTs is a genuine problem — applications with strict requirements around immediate access revocation — some systems use token introspection instead, where an opaque (non-self-contained) token is validated by calling back to a central authorization server on each request, trading away the scalability benefit of stateless verification for the ability to revoke access instantly. This is a deliberate architectural tradeoff rather than a strict improvement: introspection reintroduces the central lookup that JWTs were designed to avoid, so it’s typically reserved for applications where instant revocation is a hard security requirement that outweighs the scalability cost.