JSON Web Token (JWT)

A JWT is a compact, self-contained string consisting of three Base64Url-encoded segments separated by dots (.): Header.Payload.Signature. This structure makes it ideal for transmission in HTTP headers (like Authorization: Bearer <token>) or URL query parameters, as it avoids characters that have special meaning in URLs.

• Compactness: Encodes a complete set of claims in a small footprint.
• URL-Safety: Uses Base64Url encoding, which replaces + and / with - and _ and omits padding = where possible.

The JWT Payload contains a set of claims—statements about an entity (typically the user) and additional metadata. These claims are encoded as a JSON object, allowing the token itself to carry the necessary authentication or authorization data. This reduces the need for the recipient to query a database or authorization server for each request.

• Registered Claims: Predefined, standard claims like iss (issuer), exp (expiration time), sub (subject).
• Public Claims: Custom claims defined in the IANA JSON Web Token Registry or as URIs.
• Private Claims: Custom claims agreed upon by parties to share information.

A JSON Web Signature (JWS) provides integrity and authenticity for a JWT. The token is signed using a cryptographic algorithm specified in the header (e.g., HS256 for HMAC SHA-256, RS256 for RSA SHA-256). The signature ensures the token has not been tampered with and verifies the identity of the issuer.

• Signature Creation: The signing input is the encoded header and payload, concatenated with a dot.
• Signature Verification: The recipient recalculates the signature using the same algorithm and secret/key. A mismatch indicates tampering.
• Common Algorithms: HS256 (symmetric), RS256/ES256 (asymmetric).

A JSON Web Encryption (JWE) provides confidentiality for a JWT's contents. While a signed JWT's payload is Base64Url-encoded but readable, an encrypted JWE's payload is ciphertext, protecting sensitive claims from being read by unauthorized parties. JWEs use cryptographic algorithms to encrypt the payload and optionally the encryption key.

• Encryption Process: The payload is encrypted, and the resulting ciphertext is included in the token structure.
• Key Management: Supports various key encryption algorithms like RSA-OAEP or direct encryption with a shared secret.
• Combined Use: A JWT can be signed then encrypted (nested JWT) for both integrity and confidentiality.

JWTs enable stateless authentication for APIs. Because the token is self-contained and verifiable via its signature, the API server does not need to maintain a server-side session store. The server validates the signature and checks the claims (like exp) on each request. This architecture is highly scalable for distributed systems and microservices.

• Scalability: No shared session state required across servers.
• Performance: Eliminates database lookups for session validation on each request.
• Trade-off: Token revocation before expiration requires implementing a token blocklist or using short-lived tokens with refresh tokens.

JWTs are defined by a suite of IETF standards, ensuring broad interoperability across different programming languages, frameworks, and platforms. Libraries for creating, parsing, signing, and verifying JWTs are available for virtually all modern tech stacks.

• Core Standards: RFC 7519 (JWT), RFC 7515 (JWS), RFC 7516 (JWE).
• Wide Adoption: Native support in API gateways, identity providers (like Auth0, Okta), and cloud platforms (AWS, Azure).
• OAuth 2.0 & OpenID Connect: The standard bearer token format for OAuth 2.0 access tokens and the core artifact for OpenID Connect ID Tokens.