A remote MCP server accepts any well-formed, unexpired access token from its authorization server, including tokens that were issued for a separate reporting API. What must the server do instead?
Select an answer to reveal the explanation.
Short Explanation
A token's like a ticket printed for one specific show. Same box office, different show, and you still don't get in. If your server isn't checking the audience, it's letting tickets for other APIs through the door.
Full Explanation
The authorization specification says MCP servers, acting as OAuth 2.1 resource servers, must validate access tokens and must validate that tokens were issued specifically for them as the intended audience, per RFC 8707. Servers must only accept tokens valid for their own resources and must not accept or transit any other tokens; invalid or expired tokens receive HTTP 401. The security best practices describe audience validation failure as one dimension of the token passthrough problem: a server that accepts tokens meant for other services breaks a basic OAuth boundary and lets attackers reuse legitimate tokens across services. Accepting tokens because the signature is valid fails by concept: one authorization server may issue tokens for many resources, so a valid signature proves who issued the token, not who it is for. Forwarding them to the reporting API fails because that is token passthrough, which is explicitly forbidden, and it would make the MCP server an unaccountable proxy. Answering with 403 insufficient_scope fails because the defect is the wrong audience, not missing scopes; the specification reserves 401 for invalid tokens and 403 for insufficient scopes on an otherwise valid token. Exam caveat: clients share the duty and must send the resource parameter so tokens are minted for the right server. Operational check: present a token whose audience is the reporting API and confirm a 401.