OpenID Connect — How the Identity Protocol Took Over the Internet

What Is OpenID Connect and Where Did It Come From

OpenID Connect (OIDC) is an open authentication protocol published on February 26, 2014 by the OpenID Foundation. Its mission was straightforward but long overdue: give developers a standardized way to verify user identity in a web application — without storing passwords and without reinventing the wheel.

Before OIDC arrived, developers often reached for OAuth 2.0 as a login mechanism. The problem was that OAuth 2.0 was designed as an authorization framework — not an authentication one. It didn't define who the logged-in user was — it only defined what they had access to. OIDC fills this gap by adding a cryptographically signed identity token — the ID Token — on top of the OAuth 2.0 structure, along with a standardized endpoint for fetching profile data.

Today OIDC powers the login flows behind Google, Microsoft, Apple, GitHub, and hundreds of enterprise SSO^?SSO: Single Sign-On — an authentication mechanism that lets a user log in once and gain access to multiple connected applications without re-entering credentials systems. It is the foundation of every application that shows a "Sign in with..." button.

OAuth 2.0 vs OIDC — Authorization Is Not Authentication

The difference between these two standards is fundamental and frequently underestimated. OAuth 2.0 answers the question: "What does this application have access to?" OIDC answers: "Who is this user?"

OAuth 2.0 issues an Access Token — a pass to an API. That token is typically opaque to the client application: it knows it has the token but not necessarily who it represents. The classic metaphor is a valet key — it lets you park the car, but doesn't open the trunk and doesn't reveal who owns the vehicle.

OIDC adds an ID Token in JWT^?JWT: JSON Web Token — a self-contained, cryptographically signed token carrying identity claims that can be verified without a server round-trip format to that toolkit. This token is digitally signed and contains verifiable claims about the user: their unique identifier, the time of login, the token issuer, and the intended recipient. The application can verify the cryptographic signature locally — without any additional network request — and confirm the identity of the person who logged in.

Three Roles in the OIDC Ecosystem

Every OIDC flow involves three parties with precisely defined roles, each mapping directly to a corresponding role in the OAuth 2.0 framework.

End-User

The person initiating login. Their password is entered exclusively on the identity provider's page — the service they are trying to access plays no part in this step and has no access to any credentials. After successful authentication, the user is automatically redirected back to the service.

Relying Party

Your application — a website, mobile service, or API — that needs to know who the logged-in user is, but instead of storing passwords itself, delegates this task to an external identity provider. This is where the name comes from: relying — literally relying on someone else. For the provider to handle logins for a given application at all, that application must first register with it — for example in the Google Cloud Console or Auth0 dashboard. The result of registration is a unique identifier (client_id) that the application attaches to every login request so the provider knows who is asking.

OpenID Provider

The authorization server compliant with OIDC and OAuth 2.0. It verifies user identity, obtains consent, and issues tokens. Examples include Google Identity, Microsoft Entra, Auth0, and Keycloak.

{
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "scopes_supported": ["openid", "email", "profile"],
  ...
}

ID Token — the Heart of the Protocol

The ID Token is what distinguishes OIDC from plain OAuth 2.0. It always uses the JSON Web Token (JWT) format and is cryptographically signed by the identity provider. This allows the client application to verify its integrity without contacting the server.

A minimal valid ID Token contains several required claims:

• iss (issuer) — identifier of the issuer, e.g. https://accounts.google.com
• sub (subject) — globally unique, immutable user identifier at the given issuer
• aud (audience) — the client_id of the application the token was issued for
• exp (expiration) — expiry time as a UNIX timestamp
• iat (issued at) — issuance time as a UNIX timestamp

The iss + sub Pair — Stable Identity

The iss + sub pair is particularly important. Together they form a globally unique, stable user identity. An email address or username can change — sub never does. Basing user identification on email instead of sub is a classic architectural mistake that leads to hard-to-debug issues after account migrations.

Nonce — Protection Against Replay Attacks

To strengthen security, OIDC also uses the nonce claim — a random value generated by the client before sending the authorization request, returned in the token. Verifying the nonce protects against replay attacks.

UserInfo Endpoint — Where the User Profile Lives

The ID Token intentionally carries a minimum of identity data. A rich user profile — first name, last name, avatar, email address, phone number, postal address — is available through a dedicated, protected endpoint: the UserInfo Endpoint.

To fetch profile data, the client application sends an HTTP GET request to this endpoint with a Bearer Access Token in the Authorization header. The response is a JSON structure containing claims — or a JWT if the provider is configured that way.

The amount of data returned depends on the scopes requested during the initial authorization:

• openid — mandatory for every OIDC flow; provides minimal identity
• profile — name, picture, locale, updated_at
• email — email address and email_verified flag
• phone — phone number and phone_number_verified flag
• address — postal address data

An important security rule: the client application must verify that the sub from the UserInfo Endpoint matches the sub in the previously received ID Token. This guards against token substitution attacks.

Microsoft and other major platforms recommend minimizing UserInfo Endpoint calls where the requested data can be included directly in the ID Token as optional claims. Each additional network request introduces latency — it's worth eliminating when data is already available in the signed JWT.

Authorization Flows — Code, PKCE, Implicit, and Hybrid

OIDC defines three core flows for obtaining tokens, determined by the response_type parameter in the authorization request.

Authorization Code Flow

This is the fundamental and most highly recommended flow. After authenticating the user, the OP does not hand tokens directly to the browser — instead, it issues a one-time, short-lived Authorization Code. The server-side application exchanges this code for tokens directly with the token endpoint (back-channel), presenting its own credentials (client_secret). The user's browser never sees the raw tokens.

Authorization Code Flow with PKCE

PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — a cryptographic mechanism securing the authorization code exchange without requiring a static client_secret is the evolution of the above for applications that cannot securely store a client_secret — single-page applications (React, Vue, Angular) and mobile applications. Before each login, the client generates a random code_verifier and computes its SHA-256 hash (code_challenge). The hash is sent to the provider with the authorization request. When exchanging the code for a token, the client sends the original code_verifier — the provider computes the hash and verifies the match. An attacker who intercepts the authorization code cannot exchange it for a token without knowing the code_verifier. The OAuth 2.1 specification formalizes PKCE as a mandatory pattern for all application types.

Implicit Flow

This is a historical relic. After authentication, the provider delivers tokens directly to the browser in a URL redirect — front-channel delivery. Tokens can end up in browser history, HTTP server logs, and be vulnerable to XSS leaks. Refresh Tokens are entirely prohibited in this flow.

Hybrid Flow

This combines elements of both flows above — some tokens are delivered front-channel (e.g. ID Token), others back-channel (Access Token, Refresh Token). Used in complex enterprise scenarios where the frontend needs quick identity access while the backend requires full API authorization. This flow requires strict validation of verification parameters (including c_hash and nonce).

Implementations and Libraries

The OpenID Foundation certifies client libraries and identity providers, providing assurance of full specification compliance. Implementing JWT parsing, cryptographic signature verification, and JWKS handling from scratch is costly and risky — it's worth using mature, certified libraries.

Key libraries by platform:

• JavaScript/TypeScript SPA — oidc-client-ts (certified, TypeScript, PKCE)
• Node.js backend — openid-client (certified, back-channel, FAPI)
• Python — Authlib (Django and Flask integrations), pyoidc (certified)
• Java/Spring — Spring Security OAuth2 Client, com.nimbusds/oauth2-oidc-sdk
• .NET/C# — IdentityModel, Microsoft.Identity.Client (MSAL)
• Go — coreos/go-oidc, zitadel/oidc (certified)

The standard starting point for every library is /.well-known/openid-configuration — the discovery document that automatically supplies all endpoint addresses and public keys. Switching providers (e.g. from Auth0 to Keycloak) often comes down to changing a single line of configuration.

OIDC in the Age of AI Agents — Non-Human Identity

For a decade, OIDC verified human identity: a user entered a password, the identity provider issued an ID Token, and the application knew who had logged in. The era of AI agents makes this model insufficient.

Today's AI systems operate without a browser and without a password. An analytical assistant scans financial data, an orchestrator sends commands to dozens of tools and APIs, a subagent processes documents in the background — none of these operations passes through a login screen. Industry reports indicate that the ratio of machine identities to human identities has exceeded 82:1. An AI agent is now a first-class security principal, not an anonymous backend service.

The problem with the traditional approach: if multiple agents share a single service account and a single client_secret, system logs can no longer say which agent made which decision, on whose behalf, and based on what permission. Every anomaly becomes unattributable — and therefore uninvestigable.

The correct architecture assigns each agent a unique, ephemeral^?ephemeral: temporary — valid only for the duration of a session or task. Once the task completes, the identity is discarded. identity scoped to a session or task, limits access to the minimum required (Least Privilege principle), applies Just-in-Time access, and eliminates long-lived shared keys. An agent registered as an OIDC client receives short-lived JWT tokens federated with the cloud provider — and never knows any global secrets.

Model Context Protocol and Authorization

Model Context Protocol (MCP), published by Anthropic in late 2024, has become the de facto standard for integrating language models with external tools: databases, APIs, file systems, and enterprise registries. From a security perspective, MCP is a transport layer — and the authentication foundation of that layer is OAuth 2.1 with mandatory PKCE.

Role Architecture in MCP

• MCP Server acts as an OAuth 2.1 Resource Server — it protects resources and requires a valid Bearer token on every request.
• MCP Client / AI agent acts as an OAuth 2.1 Client — it requests access on behalf of the user or on its own behalf.
• Authorization server (e.g. Keycloak, Auth0, Microsoft Entra) manages consents and issues tokens.

The authorization flow for a remote (HTTP) MCP server proceeds as follows. An unauthenticated client receives HTTP 401 Unauthorized with a WWW-Authenticate header pointing to a metadata document (RFC 9728). The client identifies the authorization server and initiates an Authorization Code flow with PKCE. After the user grants consent, every subsequent request carries a Bearer token — the MCP server verifies the signature, issuer (iss), expiry (exp), and audience (aud).

Local MCP servers communicating via STDIO^?STDIO: Standard Input/Output — a process communication mechanism using the operating system’s standard input and output streams. Used by local MCP servers running in the same environment as the client. often rely on environment variables, which is acceptable in an isolated development environment. In production and enterprise environments, the full OAuth 2.1 path is required.

Delegation Chains — Who Is Really Acting?

When an AI agent performs an operation on a database, the target server sees a request with a token. The key question: on whose behalf is this agent acting? Does it have an explicit, revocable, scoped permission from a specific user — or is it using a global service key that cannot be attributed to anyone?

The answer comes from a working IETF draft: OAuth 2.0 On-Behalf-Of User Authorization for AI Agents. The standard introduces two new parameters:

OBO Parameters

• requested_actor^?requested_actor: An OAuth parameter identifying the AI agent that will act on behalf of the user — shown on the consent screen so the user knows who they are authorizing — sent to the authorization endpoint. It names the specific AI agent to which the user is consciously granting access, displayed on the consent screen.
• actor_token^?actor_token: A JWT cryptographically identifying the AI agent in an On-Behalf-Of flow — the server verifies it before issuing a delegated token — a JWT identifying the agent, sent to the token endpoint. The authorization server compares the sub in the actor_token against the approved requested_actor before issuing a token.

Three Identities in One Token

1. User (Subject) — the resource owner on whose behalf the agent acts.
2. Client (Delegator) — the application through which the user initiated the action.
3. Agent (Actor) — the autonomous LLM software executing the operation.

For multi-step chains (Agent A delegates to Agent B), OAuth 2.0 Token Exchange (RFC 8693) applies. The act claim embedded in the JWT tracks the full delegation history — each step is cryptographically linked to the previous one. A financial server can check: did the algorithm analyzing the balance sheet receive explicit permission from the CFO, with what scope, and for how long?

OpenID Connect for Agents (OIDC-A)

Standard OIDC answers the question: who is the user? In the world of AI agents, a new question is needed: what is this agent, and can it be trusted? An LLM's version, provider, and runtime configuration are security attributes, not just metadata.

As of June 2026, the OpenID Foundation is developing OpenID Connect for Agents (OIDC-A) 1.0 — an extension that gives AI agents a verifiable technical identity, complementary to standard human identities.

New Agent Claims

OIDC-A defines new claims describing cognitive configuration^?cognitive configuration: the set of parameters describing what a given AI agent is: which model it uses, who provides it, and how it is configured. Analogous to a model fingerprint — the server can verify it before granting access.: agent_type, agent_model (e.g. llama-3-internal) and agent_provider. Instead of an IP address or service identifier, the relying party (RP) sees which model and environment the request originates from.

Integrity Attestation

The agent_attestation field contains a cryptographic proof compatible with IETF RATS and Entity Attestation Tokens (EAT). It confirms that the LLM instance has not been modified by the cloud provider — the relying party can verify signatures, platform status, and attestation freshness.

Delegation Context Tracking

The delegation_chain and delegation_purpose fields embedded in the token enable nested on-behalf-of authorization for complex multi-agent systems. A financial server can enforce a conditional policy: allow balance sheet reads only to agents with an attested, internally hosted model that has no public internet access.

OIDC-A remains a working standard, but the direction is clear: security in AI-native systems requires verifying not only who is logging into the system, but also what is logging in on their behalf.

Golden Rules for Secure OIDC in 2024

A solid OIDC implementation goes beyond picking the right flow. Security demands adherence to a few core principles:

1. Always use Authorization Code Flow with PKCE — for web, SPA, and mobile applications without exception. Implicit Flow is deprecated and must not appear in new deployments.
2. Identify users exclusively through the iss + sub pair. Email addresses are mutable — sub is permanent.
3. Verify the nonce in the ID Token on every login to protect against replay attacks.
4. Consider sender-constrained tokens (DPoP or mTLS) for security-critical API systems, to eliminate the risk of stolen tokens being used by unauthorized clients.
5. Implement Refresh Token rotation — after each use, the Refresh Token is invalidated and replaced with a new one. This prevents persistent exploitation of a compromised token beyond the active session window.

OpenID Connect is today an indispensable component of identity infrastructure. OAuth 2.0 answers "what do you have access to", OIDC answers "who are you" — together they form the foundation of modern application security.

Sources

• openid.net — OpenID Connect Core 1.0 — link
• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• IETF — RFC 7636: Proof Key for Code Exchange by OAuth Public Clients — link
• IETF — RFC 9700: OAuth 2.0 Security Best Current Practice — link
• IETF — RFC 8693: OAuth 2.0 Token Exchange — link
• IETF — RFC 9728: OAuth 2.0 Protected Resource Metadata — link
• Microsoft — Identity Platform and OpenID Connect protocol — link
• openid.net — OIDC Certified Implementations — link
• modelcontextprotocol.io — MCP Authorization Specification — link
• IETF Draft — OAuth 2.0 On-Behalf-Of User Authorization for AI Agents — link