01 / The operating case
What changes in a real workflow?
A client presents a token for server A to server B; B cannot infer that A’s authorization grants access to B.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision boundary
Put the check where it can stop the effect.
Use protected-resource metadata and the resource indicator in the OAuth flow; validate issuer, audience and token lifetime at B.
Architecture review / negative test
Make the boundary testable.
Protected-resource metadata tells clients where authorization is available; the resource indicator directs token issuance toward the intended MCP resource. Servers should validate audience as well as issuer and lifetime. Passing a token received by one server to an unrelated downstream API can turn a protocol credential into unintended authority.
03 / Failure and evidence
What goes wrong, and what can be proven?
Accepting any issuer-valid token enables confused-deputy and token-passthrough failures.
Retain only non-secret audience-validation result and request correlation in the access log.
04 / Canonical scope
Why this reference stands alone
MCP authentication covers the whole flow; this focused reference owns the audience-validation step and negative test cases.
Primary references