JSON Web Token (JWT)

Definition

A JSON Web Token (JWT) is a compact, URL-safe, digitally signed token format used to represent claims — such as a user's identity or permissions — that can be verified and trusted between two parties without a database lookup.

Overview

A JWT is made up of three Base64URL-encoded segments separated by dots: a header (specifying the signing algorithm and token type), a payload (the actual claims, such as user ID, issued-at time, expiry, and custom data), and a signature (computed over the header and payload using a secret key or private key). Because the signature can be verified independently, a server can trust a JWT's contents without needing to query a database or session store on every request — a property that makes JWTs attractive for stateless authentication. JWTs are commonly issued after a successful login or as the access token in an OAuth flow, then sent by the client on subsequent requests, typically in an Authorization header as a bearer token. The API server verifies the signature and checks claims like expiry (`exp`) before trusting the request. Signing can use a symmetric algorithm like HMAC-SHA256, where the same secret signs and verifies, or an asymmetric algorithm like RSA or ECDSA, where a private key signs and a public key verifies — the latter is preferred when multiple services need to validate tokens without holding the signing secret. Importantly, the payload of a standard JWT is only encoded, not encrypted — anyone who intercepts the token can read its contents, so sensitive data should never be placed in the claims. JWTs also can't be easily revoked before their expiry without extra infrastructure (like a denylist), which is why many systems pair short-lived JWT access tokens with a separate, revocable refresh token. Understanding JWTs is closely tied to session management, CORS behavior for cross-origin API calls, and general authentication design.

Key Concepts

• Three-part structure: header, payload, and signature, each Base64URL-encoded
• Self-contained — claims can be verified without a server-side lookup
• Signed (not encrypted by default), so contents are readable but tamper-evident
• Supports symmetric (HMAC) and asymmetric (RSA/ECDSA) signing algorithms
• Standard claims include issuer, subject, audience, expiry, and issued-at time
• Commonly transmitted as a bearer token in an HTTP Authorization header
• Stateless by design, reducing database load for authentication checks
• Cannot be revoked before expiry without additional infrastructure

Use Cases

Frequently Asked Questions

Related in Web