MCP token passthrough and the confused deputy

Token passthrough means accepting a token from a client without confirming it was issued to the MCP server, then sending it on to the API behind it. The specification forbids it. A server must reject tokens that do not name it as the audience, and when it calls an upstream API it must use a separate token issued for that API.

The rule protects three things. Controls that depend on the token’s audience, such as rate limits and request validation, stay in force. Logs can tell which client acted. And a token stolen from one service stops working on the next one.

Clients send the resource parameter so the authorization server can bind a token to one MCP server, when it supports that. The server’s half of the job is to read the audience claim, or an equivalent, and refuse anything issued for another resource. Scopes alone are insufficient for this, because a token for a different service can carry familiar scope names.

This one targets an MCP proxy server that uses one static client ID with a third-party authorization server and lets MCP clients register themselves. The third party remembers consent for that static client ID in a browser cookie.

An attacker registers a client with their own redirect URI and sends the victim a crafted link. The cookie makes the third party skip its consent screen, and the MCP authorization code travels to the attacker’s redirect URI.

The specification requires proxy servers to get consent for each client before forwarding to the third party. That consent page belongs to the MCP server and has these requirements:

Octri’s three sign-in options handle tokens differently, and the choice matters for this rule.

A key page and Octri signing people in to your OAuth keep the two credentials apart: the client holds a token for the MCP server, and the upstream key or token stays encrypted on Octri. In the OAuth option the person approves each client on a consent page first.

Your own authorization server works differently. Octri checks each token’s signature, issuer, expiry and audience, or introspects it, then forwards that same token to your API. This departs from the specification, which has no exception for it. We chose it for the case where the authorization server and the API belong to one owner and the API remains the final check.

If your security review requires a strict reading of the rule, Octri signing people in to your OAuth is the option that meets it.