Hi all,
I'd like to raise a topology question about the ID-JAG draft (draft-ietf-oauth-identity-assertion-authz-grant) that I expect to come up often as agentic/MCP deployments grow, and I don't think the current text resolves it from my understanding.
Topology Description:
----------------------------
- An AI coding agent (e.g. Claude Code) acts as an MCP Client. It is registered at the enterprise IdP as a *public* client (native/CLI app, PKCE, no client secret).
- The agent authenticates directly against the enterprise IdP. As per OIDC Core, the resulting ID Token's `aud` is the agent's own client_id. In the same flow the agent also obtains an access token whose audience/resource is an MCP Gateway sitting in front of it.
- The MCP Gateway aggregates several upstream MCP servers. Each upstream server is protected by its own Resource Authorization Server, and each of those independently trusts the same enterprise IdP.
- Per ID-JAG, to reach a given upstream server the Gateway needs an access token minted through the ID-JAG flow: Token Exchange at the IdP to mint an ID-JAG (aud = upstream AS) and then execute JWT-Bearer redemption at that AS.
The conflict :
-----------------
Section 4.3.3 [1], "IdP Token Exchange Processing Rules", requires that when the subject_token presented in the Token Exchange call is an identity assertion (ID Token), "the IdP MUST validate the assertion and MUST validate that the audience of the assertion (e.g. the aud claim of the ID Token or SAML Audience) matches the client_id of the client authentication of the request". In the Gateway topology above, this rule creates a dilemma where neither party can execute the exchange:
1. The agent is the audience of the ID Token, but the agent has no reason to call Token Exchange itself — it doesn't know which upstream AS/audience a given MCP tool call needs, and as a public client it's also not well positioned to be trusted with that capability directly. As defined in the draft "this specification SHOULD only be supported for confidential clients."
2. The Gateway is the party that actually needs the ID-JAG (it knows the target upstream AS), and it is the Gateway that would authenticate the Token Exchange call. But the ID Token's `aud` is the agent's client_id, not the Gateway's. Per the mandatory audience check above, the IdP must reject that exchange no matter how the ID Token reaches the Gateway (forwarded by the agent or otherwise).
From my understanding, neither party in this agent-to-gateway architecture can legally execute the ID-JAG exchange under the current specification.
Did I miss a mechanism already defined in the draft (or in draft-ietf-oauth-identity-chaining) to handle this delegation/proxy pattern?
Is there ongoing work to address multi-hop or API Gateway patterns where the identity assertion's audience differs from the calling proxy's client_id?
Thanks,
Eric
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant#name-processing-rules