An MCP server's tool must call a downstream ticketing API on the user's behalf. The client already sends the server a valid bearer token. How should the server authenticate to the downstream API?
Select an answer to reveal the explanation.
Short Explanation
The token the client gave you is a key cut for your door only. To open the ticketing API's door, you need your own key cut for that lock. Passing the client's token along is called token passthrough, and you're not allowed to do it.
Full Explanation
The authorization specification says MCP servers must only accept tokens valid for their own resources and must not accept or transit other tokens, and clients must not send tokens to the MCP server other than ones issued by its authorization server. The security best practices list token passthrough as explicitly forbidden: forwarding a client's token to a downstream service bypasses controls such as rate limiting and validation tied to the token's audience, breaks the audit trail because the downstream API cannot tell which party is calling, and lets one compromised service reach others that accept the token. The server must therefore act as its own OAuth client to the downstream API and hold a token issued for that API, for example obtained through URL-mode elicitation where the user authorizes the server directly. Forwarding the bearer token fails because that token's audience is the MCP server; using it downstream is passthrough. Returning the URL for the client to call with the same token fails because the token was minted for the MCP server, so presenting it elsewhere replays it outside its audience. Asking for the client's refresh token fails by concept: refresh tokens must stay confidential to the client and are redeemed only at the issuing authorization server. Exam caveat: the client's MCP bearer token stays unchanged throughout. Operational check: confirm the downstream request carries a token whose audience is the ticketing API.