On this page
MCP token passthrough is an authorization anti-pattern: an MCP server accepts a client's access token without establishing that it was issued for that server, then forwards it to a downstream API. The API may accept the token, but that does not prove the client was authorized to use the MCP server.
The MCP security guidance prohibits token passthrough. The practical fix is to make two explicit decisions: whether the client may call the MCP server, and whether the server may perform the requested operation at the downstream service. A successful API response cannot replace either check.
This guide explains those boundaries with a hypothetical document connector, a review worksheet and proposed tests. It is not an exploit report or a claim that any named implementation has been tested.
What token passthrough looks like
Imagine an MCP server that exposes a tool called read_document. Behind it sits a document API. A client supplies a token issued only for that API. The MCP server copies the incoming credential into its outgoing API request and returns the document when the API accepts it.
The document API may have correctly recognized its own credential. The missing decision is at the MCP boundary: was this caller allowed to use this server, through this client, for this operation? The wrapper has treated access to one service as permission to use another.
| Hop | Passthrough design | Separated design |
|---|---|---|
| Client to MCP server | The wrapper accepts a document-API token without establishing its own audience. | The server validates a token intended for the MCP resource, then authorizes the requested operation. |
| MCP server to document API | The wrapper copies the incoming bearer credential into the API request. | The server uses separately authorized downstream credentials appropriate to this user and operation. |
| Failure | A downstream success can conceal the missing MCP check. | A failed check stops the operation at the relevant boundary. |
Passthrough does not necessarily create new privileges at the document API. It can still undermine the wrapper's controls, obscure who initiated an action and expose a credential to another component. Those are useful reasons to review the design even when a demonstration only reads a harmless document.
A bearer token is not a universal credential
Presenting a bearer token to its intended resource server is normal OAuth behavior. “Bearer” describes a credential usable by its possessor; it does not mean every service should accept it. RFC 6750 describes token redirect as the risk of a token intended for one resource being mistakenly accepted by another.
Separate three questions when reviewing a request:
- Issuer: which trusted authority issued this credential?
- Audience or resource: where is this credential intended to be used?
- Permissions: which operations and records may this caller access here?
A matching scope such as documents:read does not establish the audience. Two services can use the same scope name while protecting different resources. RFC 8707 resource indicators let a client identify its intended resource so the authorization server can issue an appropriate token. Check the resource identity configured in the actual deployment, including the expected URI, rather than relying on a friendly server name.
Validate at the MCP boundary
Under the MCP HTTP authorization specification, clients identify the MCP resource in authorization and token requests. Servers must validate the intended audience and accept only tokens valid for their own resources. Invalid or expired credentials receive HTTP 401; insufficient permissions are distinguished with HTTP 403. Access tokens belong in the Authorization header, not URL query strings.
Do not equate validation with decoding a JWT. For tokens using the RFC 9068 JWT access-token profile, validation includes token type, expected issuer and audience, signature, and expiry. A readable payload or valid signature alone is insufficient. Use the appropriate trusted validation mechanism for the token format and issuer.
Opaque tokens need validation too. RFC 7662 introspection can establish token state and authorization metadata. Its literal aud field is optional, so the review question is whether the trusted validation contract establishes resource applicability, not whether every response contains one particular field. Cached results also need an explicit freshness policy.
Audience restriction is one layer. OAuth's security best current practice recommends restricting tokens to a resource server, or a small set when necessary. A valid token still does not authorize every tenant, document or tool operation exposed by that server.
Authorize downstream access separately
In the document example, the MCP server is a resource server when receiving a client request and an OAuth client when accessing the document provider. Keep those roles distinct. The downstream credential should belong to the intended user or explicitly approved application identity, with the permissions that operation needs.
The current MCP specification describes URL-mode elicitation for external OAuth. It lets an MCP server initiate a separate third-party authorization flow. The server obtains and manages those third-party tokens; they must not pass through the MCP client. The flow must bind the person completing authorization to the person who initiated it. Form-mode elicitation must not collect access tokens or API keys.
A practical design review should trace that binding through storage and use. If Alice requests a document, which connection record is selected? Could a missing record silently fall back to Bob's account or a broadly privileged service account? Give missing or mismatched authorization a defined failure path instead of a convenient fallback.
What about OAuth token exchange?
RFC 8693 token exchange can support a resource server obtaining a new token suitable for a backend service. A supported authorization server validates the exchange and applies policy. That differs from copying the original bearer token into the backend API request.
Exchange is an option only when the provider and deployment support the relevant grant and trust relationship. Verify the resulting audience, scope and identity semantics. Do not assume exchange preserves an actor chain or automatically couples expiry and revocation across both tokens. If exchange fails, forwarding the original credential is not an acceptable fallback.
A token-boundary review worksheet
Complete this record for one real tool path before generalizing to the whole server. Record configuration and evidence references, never token values.
Tool and operation:
MCP server implementation/version:
Expected MCP resource identifier:
Trusted issuer and validation component:
Operation, tenant and record authorization:
Downstream API and credential identity:
Downstream credential acquisition method:
User/tenant/connection binding:
Expiry, revocation and cache behavior:
Failure behavior at each boundary:
Credential redaction points:
Reviewer, date and evidence references:Trace one allowed request and one refused request. Include reverse proxies and authentication middleware: a validation check matters only if every relevant request passes through it. For broader access planning, pair this record with the least-privilege guide for AI agents.
How to test the boundary safely
Use only an owned, authorized test environment with synthetic records, test credentials and a mock downstream service. Configure the intended boundaries first. These are proposed cases, not tests HOL has executed or a certification checklist.
| Test fixture | Expected evidence |
|---|---|
| Valid MCP token and permitted read | The expected synthetic record is returned through the intended downstream identity. |
| Valid token intended only for another API | The MCP boundary rejects it; the mock records no downstream operation. |
| Right issuer and scope, wrong audience | Rejection despite otherwise plausible credential metadata. |
| Right audience, expired token or invalid signature where applicable | Invalid authentication is rejected before the operation. |
| Valid MCP token, insufficient operation permission | The operation is denied rather than allowed merely because authentication succeeded. |
| Missing downstream authorization or another user's connection | The operation stops without substituting a different identity. |
| Denied or unsupported token exchange | No fallback to forwarding the incoming bearer credential. |
| Diagnostic capture | Logs, traces and tool output preserve useful correlation data without credential values. |
For each case, record the fixture category, expected and observed result, whether a downstream operation occurred, and a redacted correlation identifier. Inspect mock-service records as well as the client response. A failed request that already caused a downstream action is not a clean rejection. The permission-testing worksheet explains how to separate an enforced denial from an action that was never attempted.
Common questions
Does every MCP server require OAuth?
No. MCP authorization is optional, and the cited authorization scheme concerns HTTP transports. STDIO uses different credential guidance. This article is not a reason to add a remote OAuth flow to every local process.
Is introspection itself token passthrough?
No. Sending a token to its authorized introspection endpoint for validation is different from reusing it as another API's bearer credential. Supported token exchange likewise has its own authorization-server checks.
Can tool annotations fix this?
No. MCP tool annotations describe behavioral hints; they do not enforce token audiences or resource permissions. Authentication and authorization must be enforced by the relevant services.
Reviewed November 5, 2026 against MCP version 2026-07-28, identified as current on the official versioning page. Versioned documentation can receive compatible updates. Examples and test cases are illustrative; no implementation security outcome is claimed.
