Wiki · Concept · Last reviewed August 12, 2026

OpenID Connect

OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0. It lets a relying party verify an OpenID Provider's statement about an end-user authentication event and, when authorized, obtain limited user claims. An OIDC login does not by itself authorize an API call, prove legal identity, approve an agent action, or terminate every related session.

Category: Concept Published: June 25, 2026 Modified: August 12, 2026 Last reviewed: August 12, 2026 Tags: OpenID Connect, OIDC, authentication, OAuth, ID Tokens, federation, AI agents

Definition

OpenID Connect 1.0 is an OpenID Foundation Final specification family that adds authentication and identity claims to OAuth 2.0. Its main parties are the end-user, the OpenID Provider (OP), and the relying party (RP), which is also an OAuth client. A request activates OIDC by including the openid scope.

The central artifact is the ID Token: a signed JSON Web Token containing claims about an authentication event and, optionally, the end-user. The OP assigns a subject identifier. The RP validates the assertion and then decides whether and how to create its own session or link a local account.

OIDC answers a bounded question: what does this configured issuer assert about an authentication event for this client? It does not inherently prove a person's civil identity, continuing presence, comprehension, consent to a later action, entitlement at an API, or the identity and authority of software acting for the user.

Snapshot

Current Context

As of this August 12, 2026 review, OpenID Connect Core, Discovery, and Dynamic Client Registration are Final specifications incorporating errata set 2, published December 15, 2023. They remain the normative sources for the core protocol, provider metadata, and OIDC client registration.

Deployment guidance has advanced beyond the original 2014 flow menu. RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, says clients should avoid the implicit grant and other response types that put access tokens in the authorization response. It requires PKCE for public clients, recommends it for confidential clients, applies that advice to web applications as well as native apps, and identifies S256 as the non-leaking challenge method. Core still documents implicit and hybrid flows; their presence in Core should not be mistaken for the modern default.

The surrounding specification family is also broader than login. RP-Initiated Logout and Back-Channel Logout are separate Final specifications. OpenID Federation 1.1 and its OIDC/OAuth binding became Final on May 5, 2026, adding a policy-bearing multilateral trust layer rather than changing the meaning of an ID Token. OpenID Connect Key Binding draft 02, published June 24, 2026, explores DPoP-bound ID Tokens for replay resistance between RP components; it was still a draft on the review date and is not a Core requirement.

Protocol Boundaries

ID Token. A JWT about an authentication event, issued by the OP for the RP. Common claims include iss, sub, aud, exp, and iat; nonce, auth_time, acr, and amr may add transaction or assurance context. It is not an API access token or action receipt.

Access token. An OAuth credential presented to the UserInfo endpoint or another protected resource. Its audience, scope, sender constraint, and resource-server policy govern use. Its possession does not change the intended audience of the ID Token issued alongside it.

Authorization code and refresh token. A code is a short-lived, one-time input to the token endpoint. A refresh token can obtain new tokens and needs its own storage, rotation, lifetime, revocation, and replay controls. Neither should appear in model context, browser history, analytics, or ordinary logs.

Claims and identifiers. Core guarantees only (iss, sub) as the stable end-user identifier. An email_verified value says the OP used its process to verify control of an address; it does not make the address immutable, globally unique, or sufficient for legal identity. Pairwise sub values reduce direct cross-client correlation but do not hide activity from the OP or neutralize identifying profile claims.

Authorization Code Flow

  1. Start a bound transaction. The RP selects an approved issuer and sends the browser to its authorization endpoint with response_type=code, client_id, an exactly registered redirect_uri, and a scope containing openid. It binds the response to local state and normally sends a nonce and PKCE S256 challenge.
  2. Authenticate and obtain authorization. The OP authenticates the end-user and applies its policy for the requested scopes and claims. This step can involve an existing OP session; the RP must request and evaluate fresh or stronger authentication when its risk policy requires it.
  3. Return and redeem the code. The OP sends an authorization code to the registered redirect URI. The RP verifies the callback's state and issuer context, then redeems the code at the token endpoint using the PKCE verifier and client authentication where applicable.
  4. Validate before creating a session. The RP validates the ID Token under the expected OIDC profile. It may receive an access token and, under appropriate policy, a refresh token. These artifacts stay separated by type and audience.
  5. Fetch claims only when needed. The RP can call UserInfo with the access token. It must verify that UserInfo's sub exactly matches the ID Token's sub before using the response.

The result is evidence that the OP authenticated an end-user for the RP in a particular transaction. The RP's account-linking rule, local authorization policy, session lifetime, and downstream resource decisions are additional steps.

Validation Boundaries

A production validator needs profile-specific rules rather than a generic "JWT signature valid" result:

Discovery and Registration

OpenID Connect Discovery retrieves provider metadata from a well-known configuration document. Metadata can identify the issuer, authorization and token endpoints, UserInfo endpoint, JWKS URI, supported algorithms, subject identifier types, and capabilities. The returned issuer must exactly match the issuer used to obtain the configuration and the iss later accepted in ID Tokens. TLS and certificate validation remain part of the trust path.

Discovery is safe only after the issuer itself has been admitted by policy. Accepting an arbitrary URL from a user, token, prompt, or agent and then fetching its discovery or JWKS document can turn login into server-side request forgery, key substitution, or endpoint impersonation. Restrict issuers and outbound destinations, preserve issuer-to-endpoint binding, cache metadata deliberately, and refresh keys without silently accepting a different issuer.

Dynamic Client Registration standardizes how an RP submits metadata and obtains a client_id. Redirect URIs, client display names and logos, sector identifiers, JWKS locations, grant and response types, and token-endpoint authentication methods are security and governance objects. Exact redirect matching and controlled metadata updates matter. A successful registration means the OP accepted client metadata; it does not certify the organization, approve every requested scope, or authorize later agent actions.

At larger scale, OpenID Federation can convey signed entity metadata, trust chains, metadata policy, and scoped Trust Marks. It is an additional trust-establishment layer, not a replacement for Discovery validation, end-user authentication, or local authorization.

Sessions and Logout

An ID Token describes an authentication event; it is not a continuously refreshed session oracle. The ID Token's expiration limits token acceptance, but does not by itself end the RP's local session, the OP session, OAuth access, refresh-token grants, upstream federation sessions, or work already delegated to an agent.

OIDC therefore specifies logout separately. RP-Initiated Logout lets an RP direct the browser to the OP's logout endpoint, normally discovered as end_session_endpoint; registered post-logout redirect URIs and state protect the return path. Back-Channel Logout lets the OP post a signed Logout Token to an RP. The RP validates its signature, issuer, audience, time claims, logout event, and subject or session identifier, rejects cross-JWT substitution, and clears the identified local state. Front-channel and session-management mechanisms have different browser and reliability properties.

Logout, token revocation, account disablement, and cancellation of queued agent work are separate controls. A user-facing system should say which sessions and grants ended, propagate supported logout or security-event signals, revoke refresh tokens according to policy, and provide a local emergency sign-out path when the OP is unavailable.

Agent Context

A browser agent, assistant, tool gateway, or connector may operate inside a session established with OIDC. That tells the application which end-user the OP authenticated; it does not tell a resource server which model chose an action, which runtime executed it, whether the user approved that action, or whether the tool call remains within scope.

The authentication component should terminate OIDC, validate the tokens, and expose a minimal local session or claims interface. Raw ID Tokens, access tokens, refresh tokens, authorization codes, PKCE verifiers, and session cookies should stay out of prompts, model memory, traces, screenshots, and support bundles. Prompt text is not a token-validation or authorization boundary.

Governed agent systems keep at least four identities distinct: the human subject (iss, sub), the OAuth client, the agent or workload instance, and the protected resource or tool. Each consequential tool call then needs its own audience, scope or authorization detail, local policy decision, human approval or step-up when required, and audit record.

A recent OIDC authentication may be one input to step-up policy. It is not reusable blanket consent. Before a high-impact action, the system can evaluate auth_time and agreed assurance claims, request fresh authentication, show the concrete resource and consequence, and record the user's decision separately from login.

Governance and Safety

Authentication is not authorization. Interfaces should distinguish signing in, sharing profile claims, granting API access, and approving a specific action. Collapsing those moments into one button gives agents and applications more apparent authority than the protocol provides.

Account linking can cause takeover. Linking solely on email, phone number, username, or display name ignores Core's stability rules and provider differences. Use (iss, sub), protect merge and recovery paths, and tell users when a new federated identity is attached to an account.

Claims create privacy and accuracy duties. Request the minimum claims, document their source and purpose, constrain retention, and let users correct locally stored profile data where appropriate. Pairwise identifiers reduce one form of correlation, but OP logs, public identifiers, distinctive claims, analytics, and data brokers can restore it.

Assurance is contextual. Values such as acr and amr are useful only when the issuer, RP, and governing profile agree on their meaning. A valid ID Token from an approved OP can still be inadequate for a financial, medical, employment, or administrative decision.

Federation concentrates power and failure. An OP can become a visibility, availability, account-recovery, and exclusion point. Critical services need documented provider-admission rules, alternative authentication or recovery where appropriate, incident contacts, and a way to challenge an incorrect linkage or denial.

NIST SP 800-63C-4 is a useful governance benchmark for federated systems: it requires audience restriction in its scope, documented trust agreements, disclosure of relevant terms, limits on attribute use, and redress for additionally collected attributes. It is not a claim that every OIDC deployment meets a NIST federation assurance level; that requires a system-specific assessment.

Failure Modes

ID Token used at an API. A resource server accepts an ID Token because it is signed, ignoring that its audience and profile are for the RP.

Email-based account takeover. Two issuers assert the same address, or an address is reassigned, and the RP merges accounts without a protected linking ceremony.

Authorization-server mix-up. A multi-provider client sends a code or credentials to the wrong token endpoint because the callback was not bound to the issuer selected at transaction start.

Discovery or key confusion. Untrusted input chooses the issuer, endpoints, or key source; the software verifies a signature without verifying the issuer-key relationship.

Stale assurance. An old OP session or ID Token is treated as recent user presence for a high-impact action without evaluating auth_time or requiring step-up.

Partial logout presented as complete. The RP clears one cookie while refresh tokens, other RPs, upstream sessions, or queued agent actions remain live.

Claim exhaust. Profile and authentication claims are copied into logs, agent memory, analytics, and tickets, creating a cross-system tracking record.

Minimum Evidence Record

An OIDC deployment should leave enough evidence to reconstruct an authentication and its consequences without retaining reusable secrets:

Governance Pattern

Source Discipline

Use OpenID Connect Core for ID Tokens, authentication requests and responses, claims, UserInfo, and core validation rules. Use Discovery for provider metadata and issuer binding; Dynamic Client Registration for client metadata; the relevant logout specification for logout behavior; RFC 9700 for current OAuth security practice; and RFC 8725 for JWT implementation practice. Use OAuth token and resource specifications for delegated API authority.

State status and date. The Core, Discovery, Registration, logout, and Federation documents cited below are Final; OpenID Connect Key Binding draft 02 was work in progress on August 12, 2026. Do not present a draft feature, vendor extension, or proprietary "single sign-on" behavior as a Core guarantee.

Describe results narrowly: "the RP validated an ID Token from issuer X for client Y" is supportable; "the user is who they claim to be," "the login authorized the agent," or "logout ended all access" usually is not. Preserve the relevant issuer, audience, assurance profile, claim source, session boundary, and decision date.

Spiralist Reading

Spiralism reads OpenID Connect as disciplined institutional speech: one configured issuer makes a bounded assertion about one authentication event to one relying party.

The signature does not erase context. A careful system keeps authentication, account linkage, permission, agent execution, and human consequence in separate boxes—then preserves the receipts connecting them.

Open Questions

Sources

Return to Wiki