OpenID Connect (OIDC)

The core artifact of OIDC. The ID Token is a JSON Web Token (JWT) that contains Claims about the authenticated user. Unlike OAuth 2.0 access tokens, which are opaque to the client, the ID Token is intended to be parsed and validated by the relying party.

• iss (Issuer): Identifies the authorization server.
• sub (Subject): A unique, never-reassigned identifier for the user.
• aud (Audience): Must contain the client_id of the relying party.
• exp (Expiration): Time after which the token must be rejected.
• iat (Issued At): Time the token was created.

A protected OAuth 2.0 resource that returns claims about the authenticated user. The client presents the Access Token to this endpoint to retrieve identity attributes.

• Returns claims in JSON format using a standard schema.
• Supports OpenID Connect Core standard claims like name, email, picture, and phone_number.
• Allows for distributed claims, where the endpoint returns a reference URL to fetch claims from another provider, supporting federated identity architectures.

OIDC defines three primary authentication paths to accommodate different client types and security postures:

• Authorization Code Flow: The only flow suitable for confidential clients with a backend. The code is exchanged for tokens via a direct server-to-server call, ensuring the ID Token is never exposed to the user agent.
• Implicit Flow: Deprecated for new implementations due to token leakage risks in browser history. Tokens are returned directly in the redirect URI fragment.
• Hybrid Flow: Allows the frontend to receive an ID Token immediately while the backend asynchronously retrieves the access token and a validated ID Token via the code exchange, optimizing for latency in complex apps.

OIDC enables zero-configuration integration through automated metadata discovery.

• OpenID Connect Discovery: Clients fetch the provider's JSON document at /.well-known/openid-configuration to learn endpoint URLs, supported scopes, and public keys (jwks_uri) dynamically.
• Dynamic Client Registration: Clients can programmatically register themselves with the provider, receiving a client_id and optional client_secret without manual administrator intervention, critical for multi-tenant and CI/CD environments.

OIDC uses Scopes to request specific sets of Claims about the user, providing granular access to identity data.

• openid (Required): Signals an OIDC request; returns the sub claim.
• profile: Requests default profile claims (name, family_name, given_name, picture, updated_at).
• email: Requests the email and email_verified claims.
• address: Requests the address claim, which is a JSON object containing formatted, street, locality, and country fields.
• phone: Requests the phone_number and phone_number_verified claims.

OIDC provides mechanisms to maintain and terminate user sessions across multiple relying parties, a critical feature for Single Sign-Out.

• RP-Initiated Logout: The relying party redirects the user to the provider's end_session_endpoint to clear the provider session and optionally propagate logout to other clients via back-channel or front-channel mechanisms.
• Session Management: Uses an invisible iframe (op_iframe) and postMessage to allow the relying party to detect changes in the user's authentication state at the provider without polling.
• Back-Channel Logout: The provider sends a direct HTTP POST to all registered relying parties to notify them of a session termination, enabling instant cleanup.

The authorization framework that OIDC extends. OAuth 2.0 grants limited access to resources without exposing credentials, using access tokens and refresh tokens. OIDC adds an identity layer on top by introducing the ID token—a JWT containing user claims. While OAuth answers 'What can this client access?', OIDC answers 'Who is this user?'

An extension that sender-constrains OAuth tokens by binding them to a specific client's private key. The client includes a DPoP proof—a JWT signed with its key—in each request. This prevents token replay attacks where a stolen bearer token is reused by an attacker. Essential for agentic systems where tokens traverse multiple hops and interception risk is elevated.

The Secure Production Identity Framework for Everyone provides a universal workload identity standard for dynamic environments. SPIFFE issues SPIFFE Verifiable Identity Documents (SVIDs)—short-lived X.509 certificates or JWTs—that cryptographically bind an identity (e.g., spiffe://cluster.local/agent/payment-processor) to a workload. Integrates with OIDC to bridge service identity and user identity in agentic architectures.