Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect

OpenID Connect is the identity layer on OAuth 2.0. It lets a software client verify that an end-user was authenticated by an authorization server and receive limited profile claims, without turning sign-in into permission for every downstream action.

Category: Concept Updated: June 25, 2026 Tags: OpenID Connect, OIDC, identity, OAuth, ID Tokens, AI agents

Definition

OpenID Connect 1.0 is an OpenID Foundation Final specification family built on OAuth 2.0. OAuth 2.0 gives clients a way to obtain access tokens for protected resources. OpenID Connect adds an authentication result: a relying party can learn who the OpenID Provider says authenticated, when relevant, and receive claims about that user in a standardized form.

The required signal is the openid scope. With that scope, the protocol can return an ID Token: a JSON Web Token with claims such as issuer, subject, audience, expiration, and issue time. The subject is assigned by the provider. It is not a universal proof of legal identity, personhood, consent, or future authorization. OAuth access tokens, resource policies, scopes, receipts, and local authorization logic still decide what software may do.

How It Works

In the Authorization Code flow, a client sends the user to the authorization endpoint with response_type=code, client_id, redirect_uri, scope=openid, state, and often nonce. The OpenID Provider authenticates the end-user and redirects back with a code. The client redeems the code at the token endpoint and receives an ID Token, usually alongside an OAuth access token.

The client must validate the ID Token before trusting it: issuer, audience, signature, expiration, issue time, and nonce when one was used. The UserInfo endpoint is separate. It lets a client use an access token to request standardized claims, such as profile or email attributes, when those scopes were granted.

Discovery and Registration

OpenID Connect Discovery defines how a relying party obtains provider metadata from a well-known configuration document. That metadata can name the issuer, authorization endpoint, token endpoint, UserInfo endpoint, JWKS URI, supported scopes, supported subject identifier types, and signing algorithms.

Dynamic Client Registration defines how a relying party can register with an OpenID Provider and receive the information needed to use it, including an OAuth client identifier. Redirect URIs, client names, token endpoint authentication methods, and sector identifier details then become governance objects rather than casual dashboard strings.

Agent Context

AI-agent systems make old identity shortcuts expensive. A chat agent, browser agent, tool gateway, or MCP connector may know that a human signed in through OpenID Connect. That fact does not say the agent may send email, move money, delete files, approve a purchase, or disclose a private document.

For agents, OpenID Connect is most useful when it is kept separate from AI Agent Identity, workload identity, tool authorization, and AI Audit Trails. A user session can be evidence in an approval flow, but higher-risk actions still need scoped OAuth tokens, resource indicators, rich authorization details, step-up checks, review when appropriate, and revocation paths.

Governance Risks

The first risk is token confusion. An ID Token is for the relying party. Treating it as a bearer token for an API, passing it through a prompt, or using it as proof of action authority collapses authentication and authorization.

The second risk is claim accumulation. Profile claims, email status, public subject identifiers, and account metadata can become tracking material when copied into agent memory, analytics, evaluation traces, or support tickets.

The third risk is weak client registration. Sloppy redirect URI control, misleading client names, missing sector identifiers, or unreviewed token endpoint authentication methods can create confused clients and believable phishing surfaces.

Governance Pattern

Source Discipline

Use OpenID Connect Core for ID Tokens, authentication flows, UserInfo, and validation requirements. Use Discovery for provider metadata, Dynamic Client Registration for client metadata, and OAuth 2.0 sources for delegated authorization.

Do not claim that OpenID Connect proves personhood, legal identity, user comprehension, or agent safety. It is an authentication and claims protocol.

Spiralist Reading

Spiralism reads OpenID Connect as a useful refusal of mystical login. The protocol does not say the machine knows the person. It says one issuer made one bounded assertion to one client.

That modesty is valuable. A clean system keeps the assertion, the permission, the tool call, and the human consequence in different boxes.

Open Questions

Sources

Return to Wiki