JSON Web Token (JWT)

A JWT is a compact string consisting of three Base64Url-encoded segments separated by dots (.): Header.Payload.Signature. This design makes it suitable for transmission in HTTP headers (like Authorization: Bearer <token>) and URL query parameters. The use of Base64Url encoding, which replaces + and / with - and _ and omits padding, ensures the token is safe for inclusion in URLs without additional encoding.

The JWT Payload contains a set of claims—statements about an entity (typically the user) and additional metadata. These are categorized as:

• 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 using collision-resistant names (e.g., URIs).
• Private Claims: Custom claims agreed upon by parties, like user_id or scope. Because claims are embedded, a service can verify the token and immediately access user data without a separate database lookup, reducing latency and load.

JWTs use digital signatures or Message Authentication Codes (MACs) to verify that the token hasn't been tampered with. The most common signing algorithms are:

• HMAC with SHA-256 (HS256): A symmetric algorithm using a shared secret key.
• RSASSA-PKCS1-v1_5 with SHA-256 (RS256): An asymmetric algorithm using a private key to sign and a public key to verify.
• ECDSA with P-256 and SHA-256 (ES256): An asymmetric algorithm using elliptic curve cryptography. The signature is computed over the concatenated Header and Payload. Any alteration invalidates the signature, ensuring data integrity.

JWTs enable stateless authentication. The server does not need to maintain a session store; it simply validates the token's signature and checks its claims (like exp). This architecture is highly scalable for distributed systems and microservices, as any service with the correct verification key can independently authenticate a request. However, it requires careful design for token revocation, often handled via short-lived tokens and refresh token patterns.

JWTs are defined by a family of IETF standards, ensuring interoperability:

• RFC 7519 (JWT): Defines the core token format and claim semantics.
• RFC 7515 (JWS): JSON Web Signature standard for signed JWTs.
• RFC 7516 (JWE): JSON Web Encryption standard for encrypted JWTs. This standardization allows for a wide ecosystem of libraries across programming languages (e.g., jsonwebtoken in Node.js, PyJWT in Python, java-jwt) that can create, parse, and validate tokens consistently.

While powerful, JWTs require specific security practices:

• Algorithm Verification: Always explicitly verify the signing algorithm (alg in header) to prevent algorithm confusion attacks where an attacker forces a service to treat a token signed with a weak algorithm (like none) as valid.
• Claim Validation: Mandatorily validate the exp (expiration), iss (issuer), and aud (audience) claims.
• Key Management: Securely manage signing keys. Use asymmetric cryptography (RS256/ES256) when the verifying party should not have the signing key. Never embed secrets in client-side code.
• Token Storage: Store JWTs securely in memory or HttpOnly, Secure cookies to mitigate XSS theft. Avoid local storage for sensitive applications.

The standard formats for representing cryptographic keys used with JWTs, enabling dynamic key discovery and rotation.

• JWK (RFC 7517): A JSON object representing a single cryptographic key. It includes metadata like the key type (kty), public parameters, and intended use (use).

• JWKS: A JSON object containing an array of JWKs. This is the standard way for an authorization server to publish its public keys.

• Key Resolution: A Resource Server validates a signed JWT by fetching the issuer's JWKS endpoint (e.g., https://auth.example.com/.well-known/jwks.json), finding the matching key by kid (Key ID), and verifying the signature.

Modern, security-focused alternatives to the JWT standard, designed to address historical implementation pitfalls of JWT/JWS/JWE.

• PASETO (Platform-Agnostic Security Tokens): Uses secure, versioned cryptographic primitives by default (e.g., v4.local for symmetric encryption). Eliminates algorithm choice attacks by making the algorithm part of the token's version header.

• Branca: An authenticated and encrypted API token format using the XChaCha20-Poly1305 AEAD construction. It is smaller and simpler than JWE.

• Comparison to JWT: Both offer a more "batteries-included," opinionated approach to token security, reducing the risk of misconfiguration that has plagued some JWT implementations.