What is a JWT?

Where JWTs came from

The IETF published the JWT specification as RFC 7519 in 2015, alongside the broader JOSE (JSON Object Signing and Encryption) family of standards. The motivating use case was OAuth 2 — the protocol wanted a token format that could carry claims, be cryptographically verified without a database lookup, and travel safely in URLs and HTTP headers. JWTs are now the standard token format for OpenID Connect, most modern OAuth deployments, and many internal service-to-service systems.

Anatomy of a token

A JWT is three base64url-encoded segments separated by dots. The header declares the signing algorithm and the token type. The payload is a JSON object containing claims — standard claims defined by the spec (issuer, subject, audience, expiration, issued-at) and any custom claims the issuer wants to include (user role, tenant ID, scopes). The signature is computed over the first two segments using either a shared secret (HMAC) or a public-key algorithm (RSA, ECDSA, EdDSA). Recipients verify the signature using the secret or public key; if the signature is valid and the claims pass policy checks, the token is trusted.

Signed, not secret

A common misunderstanding: JWTs are signed, not encrypted by default. Anyone who has the token can decode the payload and read the claims — base64 is encoding, not encryption. This matters for two reasons. First, do not put sensitive data in a JWT you might pass through untrusted contexts; the claims are visible. Second, the security property a JWT provides is integrity (the claims have not been tampered with) and authenticity (they were signed by the expected issuer), not confidentiality. If you need confidentiality, use the JWE (JSON Web Encryption) variant or keep the sensitive data on the server and reference it by an opaque token.

When JWTs are the right tool — and when they are not

JWTs shine as short-lived access tokens in distributed systems. The receiver verifies a signature locally and trusts the claims; no database lookup. They are the standard OIDC ID token format and the most common OAuth 2 access token format. For long-lived browser sessions, however, opaque session IDs backed by a server-side session store are often safer — you can revoke them instantly, which is much harder with a JWT, because every service that holds the public key has to be told the token is now invalid. The "blacklist a revoked JWT" pattern works but defeats half the point of using JWTs in the first place. The pragmatic answer is short access-token lifetimes (5 to 15 minutes), longer refresh tokens stored server-side, and accepting that a stolen access token is exploitable for its lifetime.

At QUANT LAB

Our SaaS platform builds use JWTs for the short-lived access tokens in our OAuth 2 flows and for service-to-service authentication inside the system. Browser sessions are typically opaque HTTP-only cookies backed by a server-side session store, because instant revocation matters for a user-facing app.

Our pen-test team regularly finds JWT-related vulnerabilities in production systems — accepting the "none" algorithm, weak HMAC secrets reused for years, missing audience checks, signatures verified with the wrong key, and tokens used past their useful lifetime. Read our Stripe webhook security guide for a related signature-verification pattern, or book a call for a code review of your token-handling layer.