Before a new remote MCP server goes live, the security team reviews how it handles the OAuth access tokens that clients send it. Which behaviour must they confirm?
Select an answer to reveal the explanation.
Short Explanation
A token is like a concert wristband: it's printed for one venue, and you don't hand it to the bar next door. The trap is token passthrough, where the server reuses the client's token upstream, and the spec flatly forbids it.
Full Explanation
Under MCP authorization, a protected server acts as an OAuth 2.1 resource server. It must validate that each access token was issued specifically for it as the intended audience, using the resource indicator the client supplied, and it must accept only tokens valid for its own resources. It must not accept or transit any other tokens. When the server needs to call an upstream API, it obtains its own credentials for that API rather than forwarding the client's token; forwarding is the forbidden token passthrough pattern, which breaks audit trails and lets a stolen token cross trust boundaries. Accepting any token from the corporate identity provider skips the audience check and is exactly the confused-deputy setup the spec guards against. Tokens belong in the Authorization header on every request and must never appear in the URI query string, where logs and proxies capture them. Tool annotations are untrusted hints about behaviour, so they cannot justify relaxing authorization on any tool. Exam caveat: these rules govern HTTP transports; stdio servers take credentials from the environment instead. Operational check: send the server a token minted for a different resource and confirm a 401, then trace one upstream call to confirm it carries the server's own credential.