01 / The operating case
What changes in a real workflow?
A client requests a token for a finance MCP server but later attempts to use it with an HR MCP server.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision contract
What the executor must check
Include the finance server canonical URI in authorization and token requests, then require the HR server to reject a token whose audience does not match.
03 / Failure and evidence
What goes wrong, and what can be proven?
A token with broad scopes but no effective audience separation can be replayed at another resource.
Correlate requested resource, issued audience and rejection at the unintended server without retaining the bearer token.
04 / Canonical scope
Why this reference stands alone
Audience validation owns the receiving-server check; this page owns the requesting-client flow.
Protocol or attack trace
Resource-targeting sequence
Client includes resource=server-A in authorization and token requests. It later sends the token to server-B.
Server-B rejects the token even if the issuer and scopes are otherwise valid.
Primary references