Nametag
ID Token
Stays with the agent. aud is the client_id. Answers who signed in — not what the API may do.
Compare
OpenID Connect vs OAuth
OIDC is an identity layer on OAuth 2.0. OAuth authorizes API access. Agents usually need both, for different questions.
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
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.
| Aspect | OAuth 2.0 / 2.1 | OpenID Connect Core |
|---|---|---|
| Question answered | Is this client allowed to do these things at this API? | Who authenticated, and to which relying party? |
| Primary artifact | Access token (opaque or at+jwt) presented to the resource server. | ID Token (JWT) presented to the client. aud is the client_id. |
| Audience | The API (RFC 8707 / RFC 9068 aud). | The relying party. Sending an ID Token to an API is a bug. |
| UserInfo | Not defined. | Optional endpoint, authorized by the access token with openid scope. |
| Agent role | Agent is the client. Tools are resource servers. | Agent is the relying party when it needs to know the user. The AS is the OP. |
| AAuth relationship | AAuth can coexist; it avoids bearer tokens and pre-registration. | AAuth reuses OIDC claim names so resources can keep their user model. |
| XAA / identity chaining | Token exchange (RFC 8693) plus JWT bearer (RFC 7523) move access across ASes. XAA starts from an ID Token at the IdP, not at the API. | ID Token (or refresh) is the subject_token that mints an ID-JAG. The ID Token still must not be sent to the resource API. |
| typ / token confusion | RFC 9068 access tokens are typ at+jwt. Untyped JWTs get accepted by sloppy RSes. | ID Tokens are not at+jwt. nonce, at_hash, aud=client_id. Different validation rules. |
Takeaway
If a design says 'the agent sends the ID Token to the MCP server', that design is wrong. The MCP server wants an access token minted for it. The agent keeps the ID Token to know who it serves.
Field notes
Agents usually need both
OIDC answers which human signed in. OAuth answers what the host may do at this tool. WIMSE/SPIFFE answers which binary is calling. AAuth answers which agent instance a stranger's HTTP API can verify. Collapsing any two of those into one JWT is the recurring incident.