OIDF · Final 2014; errata set 2 current

OpenID Connect Core 1.0 incorporating errata set 2

OpenID.Core

N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore

OIDF FinalStableIdentityFoundationField guide

User-delegated agents still need to know which human they serve. OIDC remains the way that human authenticates to the authorization server. XAA even starts from an ID Token as the subject_token.

At a glance

Problem: OAuth 2.0 does not tell the client who authenticated. OpenID Connect adds an ID Token and a UserInfo endpoint so a relying party can obtain an authenticated end-user identity.
Identity / authn / authz: Identity and authentication of the user. Authorization of API access remains OAuth. Mixing them up is the most common design error in agent stacks.

Actors

End-user
Relying party (client)
OpenID provider (authorization server + identity)

In one board · OIDC vs OAuth

Nametag stays home; pass goes to the API

Two tickets come back from the token endpoint. They look related. They are not interchangeable. Sending the ID Token to an MCP server is the classic mix-up.

User
→ Authenticates →
OpenID provider
OP
→ ID Token — aud is the client →
Agent (relying party)
Agent
→ Access token — aud is this API →
API / MCP server

Nametag

ID Token

Stays with the agent. aud is the client_id. Answers who signed in — not what the API may do.

Pass

access token

Goes to the resource. Glue it to a key with DPoP if the runtime is untrusted. Still a photocopy until you do.

OpenID Connect is the identity layer on OAuth. An ID Token is not an access token. Side-by-side.

The gap for agents

OAuth 2.0 does not tell the client who authenticated. OpenID Connect adds an ID Token and a UserInfo endpoint so a relying party can obtain an authenticated end-user identity. User-delegated agents still need to know which human they serve; OIDC remains the way that human authenticates to the authorization server.

Mixing the layers is the most common design error in agent stacks: sending the ID Token to an MCP server, treating sub as a SPIFFE ID, or assuming OIDC authorized a specific tool call. XAA even starts from an ID Token as the subject_token — at the IdP, not at the API.

Actors and trust boundaries

The end-user authenticates to the OpenID provider (OP). The relying party (the agent host / client) consumes the ID Token; aud is the client_id. The OP is also an OAuth AS. Resource servers are not OIDC relying parties and must not accept ID Tokens as access tokens.

Mechanics

Authorization Code flow (with PKCE in modern deployments) adding scope=openid. Token endpoint returns an ID Token (JWT) plus an access token (and optional refresh token). RP validates iss, aud (the client_id), exp, iat, nonce, signature; optional azp, at_hash, c_hash. UserInfo endpoint, authorized by the access token with openid scope, returns additional claims. Implicit and hybrid exist in the 2014 spec; do not use them for new agents.

OpenID Connect Core 1.0 incorporating errata set 2. Authors: N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore. Final 2014 with ongoing errata.

id_tokenfrom spec: Quoted: JWT authenticating the user to the client. aud is the client, not the API.
subfrom spec: Quoted: stable subject identifier at that issuer. Pair with iss. Pairwise subs are allowed.
nonce / at_hash / c_hashfrom spec: Quoted: replay and token-binding checks between ID Token and the code/access token.
scope=openidfrom spec: Quoted: the switch that makes an OAuth request an OIDC request.

Step-by-step flows

Flow 1

Authorization code + ID Token

1
RP redirects with scope=openid (plus others), nonce, PKCE, resource if also requesting API access.
2
User authenticates at the OP. Consent covers identity and any API scopes.
3
Token endpoint returns id_token + access_token. RP validates the ID Token locally.
4
RP keeps the ID Token. It uses the access token (audience-restricted) at APIs. Optional UserInfo call.

If a design says 'the agent sends the ID Token to the MCP server', that design is wrong.

Identity vs authentication vs authorization

Identity and authentication of the user. Authorization of API access remains OAuth (the access token). Client authentication is still OAuth client auth. AAuth reuses OIDC claim names so identity-aware resources can keep their user model without becoming OIDC RPs.

How it composes

OAuth 2.0
OIDC is an identity layer on OAuth 2.0.
OAuth 2.1
Same relationship; use 2.1-shaped code+PKCE to obtain the ID Token.
OIDC Discovery
How the RP finds the OP.
Cross-App Access (ID-JAG)
ID Token (or refresh) is the subject_token for minting an ID-JAG.
AAuth
Reuses sub/email/groups/roles; does not issue ID Tokens.
CIBA
Decoupled OIDC authentication/consent when the user is on another device.

What bites agent implementers

ID Token as access token
aud is the client. An API that accepts it is trusting the wrong audience. MCP wants an access token minted for the MCP server.
Skipping nonce
Replay of an ID Token into a different agent session. Always send and check nonce on interactive flows.
Pairwise sub surprise
The same human may have different sub values at different RPs. Do not use sub as a global person identifier across OPs either — always (iss, sub).

Stability — what you can ship

OIDF Final, 2014, errata set 2 current. Stable. Implement with RFC 9700/OAuth 2.1 practices (PKCE, no implicit). https://openid.net/specs/openid-connect-core-1_0.html

Catalog claims (short form)

id_token: JWT authenticating the user to the client. aud is the client, not the API.
sub: Stable subject identifier at that issuer. Pair with iss.
nonce / at_hash / c_hash: Replay and token-binding checks.

Implementer notes

An ID Token is not an access token. Do not send it to APIs. AAuth reuses OIDC claim names (sub, email, groups) so identity-aware resources can keep their existing user model.

Relationship to others

Primary sources

OIDC Corehttps://openid.net/specs/openid-connect-core-1_0.html