Repository navigation
Add conformance tests for Token Audience Validation (server-side) #78
Description
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
audclaims 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
audclaim
Test scenarios:
- Token with
audmatching server URI → accepted - Token with
audfor different server → rejected (401) - Token with missing
aud→ rejected (401) - Expired token → rejected (401)
Activity
cayerbe commentedon Jun 3, 2026
sronix commentedon Jul 2, 2026
I run a streamable-HTTP MCP server with OAuth in production, and getting token validation right without any conformance coverage was one of the rougher parts, so I'm happy to help with this one if you're open to a contribution.
One thing I couldn't tell from the issue: in server mode the runner connects to an already-running
--url, so the server can't learn the mock AS location at launch. Is the intent that the CLI runs the mock AS on a known port and the operator configures the server to trust it (and expect its own--urlas the audience) before running the suite?If that's roughly right, I'd follow the issue as written: a mock AS that actually signs (metadata plus JWKS), one scenario with the four checks, tested against a real SDK and against my own server.
JohnA3421 commentedon Oct 8, 2026
Hi! I’m interested in contributing server-side token audience conformance coverage for this issue, using AI assistance with human review.
I reviewed the existing tests and closed PR #386. Before duplicating that work, would you welcome an external contribution here, or is this already covered by another planned effort?
If contributions are welcome, what setup should the test harness use to configure the server under test to trust the mock authorization server? I’d aim to reuse the existing infrastructure and include both passing and failing local fixtures.
I’m happy to agree on a small design before implementing.