Skip to content

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

@pcarleton

Description

@pcarleton

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions