Summary
The MCP authorization spec requires servers to validate that access tokens were issued specifically for them. This is a server-side requirement that ensures tokens cannot be reused across different MCP servers. The conformance test suite does not currently verify this behavior.
Approach
Server under test must integrate with our mock Authorization Server:
- Server configured to use mock AS's
/.well-known/oauth-authorization-server
- Mock AS serves a JWKS endpoint for token verification
- Conformance suite issues JWTs signed with mock AS's key
- Test with correct/incorrect
aud claims to verify server validates audience
The server can validate tokens either by:
- Fetching the AS's public key (JWKS) and validating locally
- Calling an introspection endpoint on the AS
Suggested Checks
Check: server-token-audience-validation
Spec: "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience"
Send token with wrong aud claim → server should reject with 401.
Check: server-token-valid-accepted
Spec: "MCP servers, acting in their role as an OAuth 2.1 resource server, MUST validate access tokens"
Send token with correct aud claim → server should accept.
Exact Spec Language
Token Handling
| Keyword |
Statement |
| MUST |
MCP servers, acting in their role as an OAuth 2.1 resource server, MUST validate access tokens |
| MUST |
MCP servers MUST validate that access tokens were issued specifically for them as the intended audience |
Token Audience Binding and Validation
| Keyword |
Statement |
| MUST |
MCP servers MUST validate that tokens presented to them were specifically issued for their use |
Access Token Privilege Restriction
| Keyword |
Statement |
| MUST |
MCP servers MUST validate access tokens before processing the request |
Implementation Notes
Mock AS needs to:
- Serve AS metadata with
jwks_uri
- Serve JWKS endpoint with public key
- Issue JWTs with configurable
aud claim
Test scenarios:
- Token with
aud matching server URI → accepted
- Token with
aud for different server → rejected (401)
- Token with missing
aud → rejected (401)
- Expired token → rejected (401)
Spec References
Summary
The MCP authorization spec requires servers to validate that access tokens were issued specifically for them. This is a server-side requirement that ensures tokens cannot be reused across different MCP servers. The conformance test suite does not currently verify this behavior.
Approach
Server under test must integrate with our mock Authorization Server:
/.well-known/oauth-authorization-serveraudclaims to verify server validates audienceThe server can validate tokens either by:
Suggested Checks
Check:
server-token-audience-validationSpec: "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience"
Send token with wrong
audclaim → server should reject with 401.Check:
server-token-valid-acceptedSpec: "MCP servers, acting in their role as an OAuth 2.1 resource server, MUST validate access tokens"
Send token with correct
audclaim → server should accept.Exact Spec Language
Token Handling
Token Audience Binding and Validation
Access Token Privilege Restriction
Implementation Notes
Mock AS needs to:
jwks_uriaudclaimTest scenarios:
audmatching server URI → acceptedaudfor different server → rejected (401)aud→ rejected (401)Spec References