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

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.

The OIDC flow follows the OAuth 2.0 Authorization Code + PKCE pattern, with one critical addition: the openid scope. When a client includes openid in its authorisation request, the authorisation server returns both an access token and an ID token from the token endpoint. The ID token is a JWT with a mandatory set of claims: iss (issuer — the identity provider’s URL), sub (subject — a stable, unique identifier for the user within this issuer), aud (audience — the client ID), exp and iat (expiry and issued-at), and nonce (a client-generated random value included in the authorisation request and echoed in the ID token, binding the token to the specific session and preventing replay). Optional but standard claims include name, email, email_verified, phone_number, preferred_username, picture, and locale; extended claims are returned from the UserInfo endpoint (GET /userinfo with the access token as a Bearer credential). The discovery document at <issuer>/.well-known/openid-configuration is a JSON document that publishes the provider’s token endpoint, authorisation endpoint, JWKS URI (where the provider’s signing keys are published for token verification), supported scopes, supported response types, and claims supported — enabling clients to configure themselves without hardcoded endpoint URLs. A client verifies an ID token by: fetching the JWKS from the JWKS URI, finding the key matching the token’s kid header claim, verifying the JWT signature, checking iss matches the expected provider, checking aud contains the client’s ID, checking exp is in the future, and checking the nonce matches what was sent — this is the complete verification sequence; omitting any step is a security vulnerability.

OIDC’s most significant infrastructure use case beyond user-facing SSO is workload identity federation: using OIDC-issued tokens as credentials for machine-to-machine access without static secrets. Kubernetes issues service account tokens (since Kubernetes 1.21, projected service account tokens are OIDC JWTs signed by the cluster’s OIDC provider, discoverable at the cluster’s /.well-known/openid-configuration) that pods can present to external services. AWS STS’s AssumeRoleWithWebIdentity API accepts a Kubernetes service account JWT and, if the cluster’s OIDC issuer is registered as a trusted identity provider in the AWS account, returns temporary IAM credentials — no AWS_ACCESS_KEY_ID stored anywhere, the pod’s identity is its Kubernetes service account. GCP Workload Identity Federation and Azure AD federated credentials work identically. SPIFFE/SPIRE’s OIDC federation endpoint issues JWT-SVIDs as OIDC tokens, allowing SPIRE-identified workloads to access cloud APIs through the same mechanism. On the Kubernetes control plane, the API server itself acts as an OIDC relying party: --oidc-issuer-url, --oidc-client-id, and --oidc-username-claim configure it to accept OIDC JWTs from an external identity provider (Dex, Keycloak, Okta, GitHub) as kubectl authentication tokens, enabling SSO for cluster access without distributing static kubeconfig credentials. cert-manager uses OIDC tokens for ACME DNS-01 and HTTP-01 challenge solvers when authenticating to cloud DNS providers, and Vault’s JWT/OIDC auth method accepts OIDC tokens as Vault login credentials — mapping OIDC claims to Vault policies. The PQC implication for OIDC is the same as for any JWT-based system: the ID token and service account token signatures are ECDSA or RSA today; migrating the identity provider’s signing key to ML-DSA propagates quantum-safe signatures into every federated authentication decision downstream.

Related

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.

LDAP (Lightweight Directory Access Protocol)

Identity Networking Directory Authentication Standards Pki
LDAP (Lightweight Directory Access Protocol) is a client-server protocol for accessing and modifying a directory service: a specialised database optimised for read-heavy, hierarchically-organised identity data. It was derived from the X.500 directory standard in the early 1990s, stripping out OSI transport dependencies to run over TCP/IP, and standardised in its current form in RFC 4511 (LDAPv3, 2006). A directory in the LDAP sense is not a general-purpose database — it is a tree of entries (also called objects), each identified by a Distinguished Name (DN) that encodes its position in the hierarchy: cn=alice,ou=users,dc=example,dc=com. Each entry is an instance of one or more object classes (defined in a schema), and each object class defines a set of mandatory and optional attributes — typed, multi-valued fields such as uid, cn (common name), mail, userPassword, memberOf, sshPublicKey, objectClass, and userCertificate. The schema is extensible: LDAP servers ship with standard schema files (RFC 2307 for POSIX users and groups, RFC 4519 for person entries) and organisations add custom schema for application-specific attributes. The tree structure makes hierarchical policy delegation natural — all objects under ou=engineering,dc=example,dc=com can be administered by a different set of ACL rules than objects under ou=ops.

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.