Learning outcomes
- Explain why token passthrough breaks audience and server accountability.
- Validate an access token at the MCP server for its own resource identity.
- Select token exchange, upstream OAuth brokerage, or service-owned authority for downstream access.
- Test wrong issuer, audience, client, user, resource, and passthrough failures.
Protocol roles
In remote MCP over HTTP, the MCP client requests access to an MCP server as a protected resource. The authorization server issues an access token for that resource. The MCP server is the resource server and validates the token. A downstream API is a different resource server and should receive a credential issued for itself.
Token passthrough occurs when the MCP server accepts a token it did not validate for itself and forwards it to the downstream API. The MCP security guidance forbids this pattern. It breaks the resource boundary, hides the client from the MCP server, and can bypass controls at either service.
Message flow
- The MCP client discovers the MCP server's protected-resource metadata through the current authorization flow.
- The client obtains an access token for the MCP server resource.
- The client sends that token to the MCP server over authenticated HTTPS.
- The MCP server validates exact issuer, audience or resource, signature or status, time, token type, client or sender context when required, and current route policy.
- The server authorizes the named MCP operation and tool resource.
- When a tool needs a downstream API, the server uses a separately registered service credential, performs an explicit token exchange, or asks an upstream OAuth broker for a per-user token for that downstream audience.
- The downstream API validates its own credential and applies local permission.
Do not place either credential in model context, tool arguments, or logs. Preserve subject and actor context through an explicit mechanism.
Validation and failure cases
At the MCP server, reject a valid token for the downstream API, another MCP server, another tenant, or another issuer. Reject a token with no acceptable audience, expired time, wrong type, invalid signature, revoked status, or insufficient current permission. Do not use an unverified token claim to select an arbitrary metadata or key endpoint.
At the downstream API, reject the MCP-server token. Accept only the credential issued or exchanged for that API. Validate its subject, actor, audience, scope, and local resource permission.
Test a downstream token presented to the MCP server, an MCP token forwarded to the downstream API, a token from another client and user, a broad multi-audience token, a copied token through another MCP server, and a disconnected upstream OAuth grant.
Design tradeoffs and residual risk
Service-owned credentials simplify automation and act with service authority rather than the user's authority. Per-user upstream OAuth preserves user context and adds consent, token custody, and provider availability. Token exchange can attenuate authority and adds another high-trust issuer.
Audience restriction limits cross-resource replay. It does not stop replay at the intended audience, prove user intent, or grant object permission. Use sender constraint, short lifetime, action policy, and secure custody as needed.
Pomerium boundary
Pomerium documents an MCP-aware upstream OAuth bridge. It can authenticate the user to the MCP route and manage upstream access tokens per user and route for supported configurations. Operators must configure approved metadata domains, provider credentials, route policy, and downstream scopes. The MCP server and downstream API still own their resource and action authorization.
Exercise
Draw one MCP tool that calls a third-party API. Record the issuer, audience, subject, client, storage, and validator for the MCP token and downstream token. Show where exchange or brokerage occurs.
Run the six wrong-token tests. Inspect logs and traces to confirm that no credential appears and that the denial identifies the invalid resource boundary.
Evaluation checklist
- Is the MCP server a named protected resource with its own token audience?
- Does it validate the token before any tool call?
- Does the downstream API receive a separate credential issued for itself?
- Are subject and actor preserved without bearer-token forwarding?
- Can every wrong issuer, audience, user, client, and resource test fail safely?
Next learning unit
Token Issuer and Audience
Accept a token only from a trusted issuer and only at the resource audience for which the token was issued.
