MCP token boundaries: why OAuth login is not enough for two hops

One login can hide two resource boundaries

An agent connects to a remote MCP service, and that service calls a protected API on the user's behalf. Successful OAuth sign-in leaves a question unanswered: which service is each access token intended for? In the documented HTTP model, the MCP client is an OAuth client; the protected MCP server is a resource server, meaning the service receiving the client's token. An authorization server issues the token for use at MCP.[1]

When the MCP server calls the upstream API as an OAuth client, it takes on a second role. That API receives a separate token issued by its authorization server. MCP must not forward the token received from its own client.[2]

A builder choosing this integration needs evidence of both token recipients. Login alone cannot supply it. Recipient separation is a required design boundary in the reviewed profile, not a certification that a particular integration is secure.

Compare recipients, not token names

Token audience means intended recipient. It need not be a visible aud field in a JSON Web Token (JWT): MCP allows an audience claim or another way to verify the recipient. RFC 8707 describes audience information in JWTs or token-introspection responses.[2][4]

These roles do not require two identity vendors or two physical authorization servers. The specification leaves authorization-server implementation details out of scope and allows hosting with the resource server or separately.[1]

Scope and audience answer different questions. RFC 8707 says scope typically describes what access is requested, while resource identifies where it will be used; some deployments encode resource identity in scope.[4] A correct recipient still does not prove permission to act on a particular record. RFC 9700 separately describes restrictions on resources and actions.[7]

A resource parameter is a request, not an issuance result

The MCP 2026-07-28 profile requires resource in both authorization and token requests. It identifies the intended MCP server by its canonical URI, and clients must send it even when the authorization server does not support it.[1] The security page conditions the audience-binding benefit on authorization-server support.[2]

These clauses distinguish a request from its result. A resource field names the requested destination; it does not prove that the issuer restricted the token or that the receiving service enforced that restriction. MCP must still validate the intended recipient.[1][2] An integration review therefore needs to separate requested resource, issued audience restriction and recipient enforcement.

The underlying RFC 8707 is less prescriptive: client resource indication is MAY, and authorization-server audience restriction is SHOULD. It permits mapping the resource URI to another audience identifier, so exact equality between that URI and a visible aud string is not a universal validation rule.[4] This flexibility does not weaken MCP's stronger client requirements.

A multi-audience bearer token is another counterexample to strict isolation. RFC 8707 permits multiple resource values but encourages a single resource: one intended recipient can use a multi-audience token at another, requiring substantial trust.[4] An audience restriction is therefore not necessarily single-recipient isolation. Generic OAuth flexibility does not exempt MCP from separate-upstream-token and no-passthrough requirements.[2]

Discovery cannot settle the trust question either. MCP requires protected-resource metadata for authorization-server discovery.[1] RFC 9728 requires resource-identity validation but leaves secure selection of appropriate authorization servers for every use case out of scope.[5] Finding an endpoint is not enough to establish that its issuer should be trusted.

A hypothetical CRM integration makes the difference visible

Consider an agent reading one contact through a customer relationship management (CRM) API. The comparison below is hypothetical and unexecuted. "MCP token" and "CRM token" label roles, not real credentials or provider behavior.

If the CRM call worked in the passthrough design, it would show upstream acceptance, not that MCP was entitled to accept the incoming credential. The separated design is a candidate for further evaluation. Two different token values alone do not establish valid issuance, recipient validation or delegation for the requested action.

Correct audiences do not prove client-specific consent

The MCP best-practices document describes a confused-deputy problem: a proxy is induced to act for a client without the user's proper consent. The documented attack requires combined conditions: a static upstream client ID, dynamically registered MCP clients, a prior upstream consent cookie, and missing per-client consent before forwarding to upstream authorization. It is not a claim about every proxy or dynamic registration flow.[3]

The upstream authorization server sees the proxy's static client identity; the user may be dealing with a different downstream MCP client. Prior consent to the proxy does not establish consent to that requesting client. In this static-client-ID proxy situation, MCP requires consent for each dynamically registered client before forwarding to third-party authorization.[2][3]

The prescribed controls include approved client IDs per user and a consent screen showing the requesting MCP client, upstream scopes and registered redirect URI. Consent is bound to the specific client ID, not a generic "user has consented" state.[3] These controls identify who the user authorized to initiate delegation, rather than where the token may be used.

For the hypothetical CRM service, an audience-correct CRM token could still leave the requesting MCP client's consent relationship unexplained. That is a separate unresolved question, not proof that an attack occurred. The best-practices document also warns against treating claimed scopes as sufficient without server-side authorization logic.[3]

PKCE protects code redemption, not every issuer choice

Proof Key for Code Exchange (PKCE) connects an authorization-code exchange to a secret verifier created for that request. An interceptor lacking that verifier cannot redeem the code, as RFC 7636 explains.[6] MCP requires clients to verify advertised PKCE support before proceeding and use S256 when technically capable. Under this edition, missing code_challenge_methods_supported metadata requires refusal.[2]

An authorization-server mix-up is a different failure: the client sends a code from an honest server to an unintended token endpoint. MCP's best-practices explanation says PKCE alone does not prevent its documented mix-up because the client sends the verifier to the attacker's endpoint too; resource indicators do not help when interception happens before the honest authorization server.[3] This is a source-described threat, not an attack we executed.

In this edition, the client must record the selected authorization-server issuer from validated metadata before redirecting the user. It then validates the response before sending the code to any token endpoint. A present iss parameter identifies the response's issuer: decode it from the form-encoded response, compare it to the recorded issuer using simple string comparison without URI normalization, and reject a mismatch.[1][8] This exact comparison rule differs from resource-to-audience mapping.

The last row leaves a gap: absent iss with false or absent support permits proceeding at this check, without response-issuer binding. MCP authorization-server inclusion of iss is SHOULD in this edition; a server including it must advertise support.[1] The best-practices page says this mitigation provides no protection when the honest server emits no iss.[3] Nor does it protect a client whose expected issuer came from unvalidated metadata.[1]

RFC 9700 discusses issuer binding and distinct redirect URIs as mix-up defenses.[7] Those generic alternatives do not establish that a specific MCP client implements them, nor permit ignoring this MCP profile's exact response-validation requirements. PKCE, recipient restriction and issuer-response binding address different points in the flow.

Choose on the delegation evidence, not the login screen

For a protected remote HTTP MCP service calling another API as an OAuth client, reject incoming-token passthrough under the reviewed profile.[2] Prefer a candidate that can substantiate separate MCP and upstream recipient boundaries. This warrants further evaluation, not a complete security verdict.

To move from unresolved to a candidate worth evaluating, seek version-specific implementation documentation of resource support and issuance, each recipient's validation mechanism, and how the upstream grant connects the user and requesting MCP client to the action. Applicable client-specific consent, operation permission and missing-issuer behavior also need answers. The sources here supply requirements and mechanisms, not those provider-specific answers.

If documentation leaves a consequential gap, separately authorized implementation evidence may be needed. This research provides no runtime assurance, provider ranking, SDK compatibility finding or measured reduction in attacks. A two-token architecture does not by itself solve prompt injection, token leakage or every delegation threat.

Method, dates and limits

This is a purposive documentary comparison, not a statistical sample or interoperability experiment. We read the relevant passages in the official MCP authorization, security-considerations and security-best-practices pages at the exact 2026-07-28 paths, alongside RFC 8707, RFC 9728, RFC 7636, RFC 9700 and RFC 9207. For each, we separated role, normative obligation, capability condition and failure mode. The MCP pages belong to one documentation family, not three independent confirmations.

All sources were retrieved on 4 October 2026 KST. The MCP edition label is not an announcement or launch date; page publication and update dates were not established. The main specification cites an OAuth 2.1 draft, not a completed OAuth 2.1 RFC.[1] The supporting RFC publication dates are given in the source notes, and selected relevant passages—not every section of every RFC—were reviewed.

No account was connected, no credential or token collected, no protected API called and no attack or SDK executed. The observations are source text; the comparison and adoption rule are our synthesis. Neither implementation prevalence nor end-to-end security follows from standards compliance language alone.