↓ Skip to main content
Le Site de François
  1. Index/

JWT (JSON Web Token)

Security Identity Cryptography Oauth2 Oidc Tokens Standards

JWT (JSON Web Token), standardised in RFC 7519, is a compact, self-contained token format that encodes a set of claims — assertions about a subject, an issuer, an audience, and arbitrary application-defined attributes — as a JSON object, signs or encrypts it, and serialises the result as three base64url-encoded segments separated by dots: header.payload.signature. The header is a JSON object specifying the algorithm (alg) and optionally a key ID (kid) used to produce the signature. The payload is a JSON object containing the claims. The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm declared in the header. The entire token is URL-safe, fits in an HTTP header or query parameter, and is self-describing — a verifier can locate the signing key, check the algorithm, verify the signature, and read the claims without any external lookup beyond fetching the issuer’s public key. This self-contained nature is what makes JWTs efficient at scale: unlike opaque tokens, which require a network call to the issuer’s introspection endpoint per verification, a JWT can be verified locally with a cached public key, making it suitable for high-throughput API gateways and distributed systems.

A JWT carries a defined set of registered claims with standardised semantics, alongside application-defined private claims. The registered claims are: iss (issuer — the URL of the party that signed the token, e.g. https://accounts.google.com), sub (subject — a stable identifier for the entity the token represents, e.g. a user ID or a Kubernetes service account), aud (audience — the intended recipient(s) of the token; a verifier must reject tokens where its own identifier is not in aud), exp (expiry — a Unix timestamp after which the token must be rejected), nbf (not-before — the token must be rejected before this time), iat (issued-at — when the token was created), and jti (JWT ID — a unique identifier for the token, used to implement single-use tokens and revocation). Omitting aud verification is one of the most common JWT security vulnerabilities: a token issued for one service can be replayed against another service that accepts the same issuer but does not check the audience. The complete verification sequence is: fetch the JWKS from the issuer’s JWKS URI (cached; refresh on unknown kid), find the key matching the token’s kid, verify the signature, check iss matches the expected issuer, check aud contains the verifier’s identifier, check exp is in the future, check nbf is in the past if present — every step is mandatory. The alg: none attack (stripping the signature and setting algorithm to none) is prevented by rejecting any token whose algorithm is not in an explicit allowlist configured at the verifier; libraries that accept any algorithm declared in the token header are vulnerable.

JWT is the serialisation format that unifies the token layer of this glossary’s identity stack. OAuth 2.0 access tokens are JWTs signed with the authorisation server’s private key (RS256, ES256, or EdDSA), carrying scope or scp claims that resource servers evaluate for authorisation. OIDC ID tokens are JWTs with the additional nonce claim binding them to a specific authentication session. Kubernetes service account tokens are JWTs issued by the API server’s built-in OIDC provider, carrying kubernetes.io namespace claims that AWS STS, GCP Workload Identity Federation, and Vault’s JWT auth method can verify to grant cloud or secret access without static credentials. SPIFFE JWT-SVIDs are JWTs carrying a spiffe:// URI as the sub claim, signed by the SPIRE server’s CA, used where mTLS is not available. TOTP authenticator app provisioning secrets are sometimes distributed as JWTs in provisioning flows. The JWS (JSON Web Signature, RFC 7515) and JWE (JSON Web Encryption, RFC 7516) specifications define the full signed and encrypted JWT formats respectively; the JOSE (JSON Object Signing and Encryption) umbrella covers all four: JWS, JWE, JWK (JSON Web Key, RFC 7517) for key representation, and JWA (JSON Web Algorithms, RFC 7518) for algorithm identifiers. The PQC transition requires migrating JWT signing keys from RS256/ES256/EdDSA to ML-DSA: the JWT alg header would carry an ML-DSA OID, and the issuer’s JWKS endpoint would publish the ML-DSA public key in JWK format. The IETF JOSE working group is actively standardising ML-DSA and ML-KEM algorithm identifiers for JWA; until those identifiers are finalised and library support lands, hybrid signing (producing both an ES256 and an ML-DSA signature in parallel) is the recommended transition approach for high-assurance token issuers.

Related

OAuth 2.0

Security Identity Authorisation Api Tokens Standards
OAuth 2.0 (RFC 6749, 2012) is an authorisation delegation framework — not an authentication protocol — that solves a specific problem: how does a user grant a third-party application access to their resources on a server, without giving that application their password? The canonical example is a user granting a calendar app access to their Google Drive files: OAuth 2.0 lets Google issue the calendar app a scoped, time-limited access token that permits it to read Drive files, without the app ever seeing the user’s Google password. The distinction between authorisation and authentication is fundamental: OAuth 2.0 proves that a token was issued by an authorisation server for a specific scope — it says nothing about who the user is. Attempting to use OAuth 2.0 for authentication (treating token possession as proof of identity) is a well-documented anti-pattern with concrete exploits; OIDC (OpenID Connect) is the authentication layer built on top of OAuth 2.0 that addresses this correctly.

OIDC (OpenID Connect)

Security Identity Authentication Sso Federation Kubernetes Standards
OpenID Connect (OIDC) is an authentication protocol built as a thin layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Where OAuth 2.0 defines how to delegate authorisation (granting access to resources), OIDC adds the missing authentication semantics: a standard ID token that proves who the user is, a UserInfo endpoint that returns standardised identity claims, and a discovery document that allows clients to configure themselves automatically from a single well-known URL. The separation is precise: OAuth 2.0 access tokens prove that a client is authorised to call an API; OIDC ID tokens prove that a specific user authenticated with a specific identity provider at a specific time. OIDC is the protocol behind virtually every “Sign in with Google / GitHub / Microsoft” flow, every SAML-to-modern-stack migration, and every Kubernetes service account token issued today — making it the dominant authentication federation standard in cloud-native infrastructure.

PKI (Public Key Infrastructure)

Security Cryptography Certificates Identity Tls Pki
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.