Add conformance tests for Token Audience Validation (server-side)

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:

1. Server configured to use mock AS's /.well-known/oauth-authorization-server
2. Mock AS serves a JWKS endpoint for token verification
3. Conformance suite issues JWTs signed with mock AS's key
4. 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:

1. Token with aud matching server URI → accepted
2. Token with aud for different server → rejected (401)
3. Token with missing aud → rejected (401)
4. Expired token → rejected (401)

Spec References

• Token Handling
• Token Audience Binding and Validation
• Access Token Privilege Restriction

Start by locating the conformance suite's mock Authorization Server integration and server request checks, then review how metadata, JWKS, and JWTs are currently handled. Add the named audience-validation checks and ensure the suite covers matching, wrong, and missing aud claims, plus expired tokens, with accepted requests succeeding and invalid tokens returning 401.