MCP OAuth Token Audiences: Why Passthrough Reaches a Different API

The access token an MCP client presents to an MCP server and the token that server presents to an upstream API belong to separate authorization relationships. The stable MCP 2026-07-28 specification requires clients to identify the MCP server with resource in both authorization and token requests. It also requires the server to accept only tokens issued for its own resource and forbids forwarding the client's token to an upstream API. Reusing one bearer token across both hops is therefore not neutral plumbing. It removes the boundary that keeps permission for one resource from being exercised through another.

Two authorization relationships

The dangerous path is straightforward. A client presents an upstream API token to the MCP server. The server fails to reject the audience mismatch and copies that bearer token into its upstream request. The token is legitimate at the upstream API, so the request may succeed with its existing permissions. Rate limits, request checks, client attribution, or audit controls expected at the MCP boundary may be bypassed. The same problem appears when a token obtained from one compromised service is accepted across several resources.

This does not mean token passthrough creates permissions absent from the token. It means the MCP server can become a path to permissions granted for a different resource, while the parties on each side may make incompatible assumptions about who validated the credential and which controls were applied.

Requirements in the current specification

An MCP client must place the MCP server's canonical URI in the resource parameter in both the authorization request and token request. The MCP server, acting as a resource server, must validate the inbound token and reject one that was not issued specifically for its resources. It must neither accept nor transit other tokens.

When the MCP server calls an upstream API, it becomes an OAuth client of that API. The upstream access token must be a separate token issued by the upstream authorization server. Sending resource is one half of this control; it does not replace validation by the recipient. A narrow scope also does not make a wrong audience acceptable.

Access-boundary evidence for adoption

An adoption record should make the two credential lifecycles visible. The following fields are an MCP Guard operational recommendation, not a protocol-mandated record format:

• the MCP endpoint's canonical URI and the resource value sent in both requests;
• allowed issuer, audience, and scopes at the MCP server, plus rejection evidence for mismatches;
• upstream issuer, account, scopes, storage location, and revocation method for each API;
• confirmation that the inbound Authorization header is never copied into an upstream request; and
• negative tests using a correct MCP token, a token for another resource, and an expired token.

Adoption is supportable when the inbound and upstream issuers, tokens, and minimum scopes are separate and each hop enforces its own audience. Require remediation before connection if the server accepts arbitrary bearer tokens, omits audience validation, or forwards the same token to another backend.

Scope and sources

This analysis reflects the stable MCP 2026-07-28 Authorization specification, its normative Security Considerations, and official Security Best Practices reviewed on September 22, 2026. It is not a fresh inspection of an individual MCP server, evidence of a token leak, or a claim about a product CVE. The table and adoption record are MCP Guard recommendations derived from the public requirements.

• MCP 2026-07-28 Authorization: resource and token handling
• MCP 2026-07-28 Authorization Security Considerations
• Official MCP Security Best Practices: Token Passthrough