OAuth Token Exchange vs Token Passthrough: Why Passthrough Fails and How to Migrate

Token passthrough, where an agent, MCP server or API gateway forwards the token it received to the next service, is the quickest way to wire up a call chain and one of the most damaging habits in agent architectures. It keeps appearing because it works on the first day. This guide compares passthrough with OAuth token exchange (RFC 8693) as two ways of answering the same question: what credential should the next hop see? It covers the threat model of each, how they fail, the controls that matter (audience restriction, the act claim, downscoping), decision criteria, a worked migration, and how to detect passthrough that is already in production. It is written for identity architects, platform engineers and AppSec teams reviewing agent and MCP deployments. For the mechanics of the exchange request itself, see the OAuth Token Exchange and Delegation Guide; this page focuses on the comparison and the move from one to the other.

Key takeaways

• Passthrough is not a design choice in MCP. The MCP authorisation specification says servers must not accept or transit tokens issued for anyone else, and that a server calling upstream APIs must use a separate token issued by the upstream authorisation server.
• Audience is the deciding property. A forwarded token either carries an audience the next hop should reject, or a broad audience that makes every hop a replay target. Exchange produces a token whose audience names exactly one next hop.
• Exchange keeps two identities; passthrough keeps one. With an actor token, the exchanged token records both the user and the agent acting for them in the act claim, so downstream logs and policy can tell them apart.
• Downscope at every hop. Each exchange should issue the intersection of what was requested, what the subject holds and what policy allows for that audience. A passthrough chain can only ever carry the full original authority.
• Migrate in rings, measure by audience. Find passthrough by comparing the audience of inbound and outbound tokens at each intermediary, add audience checks downstream in log-only mode, then switch hop by hop to exchanged tokens.

The short answer

Use token exchange (or a separate client credential at the intermediary) for every hop that crosses a service, trust or audience boundary. Treat token passthrough as an anti-pattern to remove, not an option to weigh. The MCP security best practices define passthrough as a server accepting tokens from a client "without validating that the tokens were properly issued to the MCP server" and passing them on to the downstream API, and the authorisation specification's security considerations state that the MCP server "MUST NOT pass through the token it received from the MCP client".

Side-by-side comparison

Token passthrough in depth

Threat model

The MCP security best practices describe two failures that usually travel together. The first is accepting a token whose audience is not the server, which "breaks a fundamental OAuth security boundary" and lets tokens be reused across services. The second is forwarding that token, which can cause the confused deputy problem: the downstream API "may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API". In agent systems the threats are concrete:

• Downstream replay: any intermediary that sees the token, and any log, cache or crash dump where it lands, holds a credential valid at every service that accepts its audience. RFC 9700 section 4.9 describes the same risk from counterfeit and compromised resource servers that receive valid tokens and reuse them elsewhere.
• Confused deputy: the downstream API cannot tell whether the agent, the MCP server or the user originated the call, so injected instructions that make the agent act are executed with the full user token. The Confused Deputy in AI Agents Guide covers the request-origin side of this problem.
• Control bypass: the specification notes that rate limits, request validation and monitoring that depend on token audience can be skipped if a client can use the same token directly at the downstream API.

Architecture in words

A user signs in to an agent host. The host obtains one access token with a broad audience (often the identity provider's default API audience) and many scopes. The agent calls an MCP server with it; the MCP server forwards the same bearer token to a ticketing API and a document API; the document API forwards it again to a search service. Four services now hold one credential, none of them knows which hop is speaking, and the token lives as long as the user's session.

How passthrough fails in practice

• Audience widened to make it work: teams hit 401 errors when downstream services check aud, then add every service to the audience list or switch the check off. RFC 8707 warns that a token with several audiences lets any of those resources use it at the others, which needs "a high degree of mutual trust".
• Audit trails that point at the user: downstream logs record the user as the actor for actions the agent chose. During an investigation nobody can separate what the person did from what the agent did.

Token exchange in depth

Threat model

Exchange moves the trust decision into the STS. The main threats shift accordingly: a compromised STS can mint tokens for many audiences, an exchange policy that is too permissive turns the STS into a privilege amplifier, and an unauthenticated client can launder a stolen token. RFC 8693's security considerations warn that "omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens". Delegated tokens can still be abused, which is why the RFC points to scope and short lifetimes to limit where delegated rights can be used.

Architecture in words

The agent host obtains a token whose audience is the MCP server, as the MCP specification requires through the resource parameter. The MCP server validates it, then authenticates to an STS as itself and sends a token exchange request: the inbound token as subject_token, its own credential as actor_token, resource set to the ticketing API and a narrow scope. The STS checks that this server may act for this user towards that audience, and returns a short-lived token with aud set to the ticketing API, the user in sub and the MCP server in act. The ticketing API validates aud against its own identifier and makes its decision on the top-level claims and the current actor. RFC 8693 is explicit that nested act claims are informational only, so prior hops form an audit trail, not an authorisation input. See the Agent Delegation Chains and Attenuation Guide.

Delegation or impersonation

RFC 8693 distinguishes the two. With impersonation, the intermediary receives all the subject's rights in some context and becomes indistinguishable from it. With delegation, the intermediary "still has its own identity separate from" the subject. For agents, delegation is the default you want: it keeps the agent visible in every downstream decision and log. Reserve impersonation for legacy APIs that cannot read an act claim, and compensate with tight audience and scope plus STS-side logging of the actor.

How exchange fails

• Exchange that does not narrow: the STS copies the inbound scope to the outbound token. Policy must compute an intersection.
• Free-text audiences: accepting any audience string lets a client request tokens for services it should never reach. Map audience and resource values to an allow-list per client.
• Refresh tokens on exchanged tokens: issuing them turns a short hop credential into a standing one.
• Authorising on nested actors: downstream services that grant access because some earlier actor was trusted ignore the RFC's rule that only the current actor counts.
• The STS treated as an ordinary app: it mints tokens for many audiences, so its signing keys, exchange policy and admin access need the same protection as the identity provider.

The controls that separate the two

Two adjacent IETF drafts extend the exchange model and are worth tracking, with the caveat that drafts change. Transaction Tokens (draft-ietf-oauth-transaction-tokens-11, dated 30 July 2026, waiting for write-up as checked on 13 November 2026) give internal workloads a short-lived signed context token within one trust domain instead of forwarding the external access token; see the OAuth Transaction Tokens (Txn-Tokens) Guide. The Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-06, dated 31 October 2026) uses token exchange at the enterprise identity provider to obtain an ID-JAG, which the client then presents to the resource's authorisation server as a JWT bearer grant; see Enterprise-Managed Authorisation for AI Agents (ID-JAG and Cross App Access).

Decision criteria

Two questions decide the pattern for each hop: which audience does the next service need, and must the delegation stay traceable? The answers map to five common situations.

Small organisations: the identity provider you already run usually supports RFC 8693 token exchange or an on-behalf-of flow; start there rather than building an STS. Large organisations: centralise exchange policy in one STS per trust domain, make the exchange policy reviewable as code, and assign it a tier-zero owner.

Worked scenario: an MCP server for a support desk

A support team uses an AI assistant connected to an internal MCP server. The server exposes tools that read tickets from a ticketing API and attach documents from a document store. In the original design the assistant passed the user's identity provider token, audience set to a shared "internal-apis" value with 14 scopes, straight through the MCP server to both APIs.

1. Findings: the MCP server accepted tokens with any audience; both downstream APIs accepted the shared audience; the document API logged the user as actor for agent-initiated attachments; the token lifetime matched the 8 hour session.
2. Inbound fix: register the MCP server as a resource with its own identifier. The assistant now sends resource set to the MCP server's canonical URI, and the server rejects any token whose aud does not contain it, returning 401 with a WWW-Authenticate header pointing to its Protected Resource Metadata.
3. Outbound fix: the MCP server authenticates to the STS with private_key_jwt and exchanges the inbound token for two outbound tokens, one with resource set to the ticketing API and scope tickets.read, one with resource set to the document API and scope documents.attach. Both carry act naming the MCP server and live for 5 minutes, with no refresh token.
4. Policy: the STS allows this MCP server to act only for users in the support group and only towards those two audiences; any other audience returns invalid_target.
5. Downstream: both APIs validate aud against their own identifier and write sub and act.sub to their audit logs.
6. Result: a token leaked from the document API's logs is useless at the ticketing API and expires within minutes.

Migrating from passthrough to exchange

1. Inventory intermediaries: list every agent host, MCP server, gateway and backend-for-frontend that receives a bearer token and makes outbound calls. The MCP Gateway and MCP Server Governance Guide covers building the server inventory.
2. Find passthrough: at each intermediary, compare the jti or a hash of the inbound token with the outbound Authorization header. Identical values mean passthrough. Where tokens are opaque, compare introspection results.
3. Give each resource an identity: register a distinct audience per downstream API and per MCP server. Shared audiences are the root cause of most passthrough that "works".
4. Turn on audience checks in log-only mode: each resource server logs, but still accepts, tokens whose aud does not name it.
5. Stand up exchange policy: configure token exchange at the identity provider or STS with per-client allow-lists of subject token types, audiences and maximum scopes; require client authentication.
6. Switch one hop at a time: change the intermediary to exchange for the first downstream audience, confirm success rates, then enforce audience rejection at that resource. Repeat per hop, starting with the most privileged downstream API.
7. Roll back safely: keep the log-only audience mode available behind a configuration flag for each resource for a defined period; do not roll back by widening audiences.
8. Remove the old path: once enforcement holds for a release cycle, remove the shared audience from the identity provider so new passthrough cannot be built against it.

Detection and measurement

• Audience mismatch events: log every rejected or log-only token with its aud, client_id and calling address. A rise after a release usually means a new passthrough path.
• Same jti at more than one resource server: correlate jti values across API gateways. A token seen at two audiences was forwarded or replayed. This aligns with ATT&CK T1550.001 Use Alternate Authentication Material: Application Access Token, and with T1528 Steal Application Access Token for the theft that precedes it.
• Exchange anomalies at the STS: exchanges requesting new audiences for a client, scope requests at the policy ceiling, and invalid_target spikes.

Metrics that show the migration is working:

1. Percentage of resource servers enforcing audience validation (target 100 percent).
2. Number of intermediaries where inbound and outbound tokens match (target zero).
3. Median lifetime of tokens presented to downstream APIs by agents (target minutes).
4. Percentage of agent-initiated downstream requests carrying an act claim.
5. Average number of scopes per exchanged token compared with the inbound token.

Common failure patterns

• "The gateway validated it, so forwarding is fine": validation at the edge does not change the audience. Downstream services must still reject tokens not issued for them.
• One integration holding everyone's tokens: an intermediary that stores users' upstream tokens becomes the most valuable target in the chain. In the Salesloft Drift breach, stored integration tokens let the attacker call customer Salesforce APIs as the trusted application. Short-lived, audience-bound exchanged tokens minted per request reduce what such a store can hold.
• Proxy MCP servers with a static upstream client ID and no per-client consent: the MCP security best practices describe how a consent cookie lets an attacker's dynamically registered client skip consent; per-client consent must run before the third-party flow.

Framework mapping

Practitioner checklist

• Confirm every MCP server and API rejects tokens whose aud does not name it, with no wildcard or shared audiences.
• Require MCP clients to send the resource parameter with the server's canonical URI in authorisation and token requests.
• Replace every forwarded token with an exchanged token or a separate client grant at the intermediary.
• Send an actor token at exchange so downstream tokens carry act, and log sub and act at every resource.
• Enforce exchange policy per client: allowed subject token types, audiences and maximum scopes; refuse anything else with invalid_target.
• Keep exchanged tokens short-lived, issue no refresh tokens for them, and consider DPoP or mTLS binding.
• Implement per-client consent on any MCP proxy that uses a static upstream client ID.
• Alert on the same jti at more than one resource server and on audience mismatches.

Standards and references

• Model Context Protocol: Authorization Security Considerations
• Model Context Protocol: Security Best Practices (Token Passthrough)
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 8707 Resource Indicators for OAuth 2.0
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 9068 JWT Profile for OAuth 2.0 Access Tokens
• IETF: Transaction Tokens (Internet-Draft)
• IETF: Identity Assertion JWT Authorization Grant (Internet-Draft)

Related NHI Mgmt Group resources: OAuth Token Exchange and Delegation Guide · MCP Security Guide · MCP Authorisation Specification Guide · API Keys vs OAuth for MCP Servers · OAuth Token Theft Incident Playbook