RFC 8707 Resource Indicators Implementation

[ihrpr]

RFC 8707 Resource Indicators Implementation

Background:

Spec Changes PR
rfc8707
TS Implementation
Additional changes for not requiring strict matching

Closes: #962

---

Implements Resource Indicators validation for OAuth 2.0 (RFC 8707; spec change)
.

• Set the resource parameter in OAuth authorization and token exchange flows to bind tokens to the MCP server
• Updated token_verifier.py to show how to perform resource verification (disabled by default, run with --oauth-strict to enable)
• Validation of resource uses hierarchical matching

Motivation and Context

Facilitate prevention of token theft/confusion attacks where a malicious MCP server steals tokens meant for other services by explicitly binding tokens to their intended resources and showing how a server can check this binding.

This security vulnerability was identified in modelcontextprotocol/modelcontextprotocol#544.

How Resource Indicators Work

Clients automatically include a resource parameter in their OAuth requests that identifies which MCP server they intend to access (e.g., resource=https://api.example.com/mcp). This happens transparently without any action from developers using the SDK.

Authorization Servers (AS) receive this resource parameter and include it in the tokens they issue, typically as the aud (audience) claim in JWT tokens. This cryptographically binds each token to its intended MCP server.

MCP Resource Servers (RS) can verify that incoming tokens were specifically issued for them by checking the audience claim matches their server URL. With --oauth-strict enabled, the server rejects tokens that don't include the correct resource identifier, preventing token confusion attacks.

Breaking Changes

While the change is breaking at a protocol level, it should not require code changes from SDK users (just SDK version bumping).

• Client developers: No code changes required. The SDK automatically extracts and includes the resource parameter from the server URL
• Server developers:
  • Resource validation is left to implementors (see token_verifier.py)
  • The Authorization Server (if external) needs to support / relay the resource param, and enough of the clients need to update their SDK to start setting the resource param in their auth requests. This is why server.py only validates the resource if --oauth-strict is set.
  • Each server should ideally treat each MCP server as a distinct resource in their PRM. If they host many servers under the same domain, the resource should be specific to a single server, not be domain-wide (otherwise any "bad apple" server might be able to benefit from resource confusion w/ its siblings).
• Auth providers: should be updated to accept and relay resource parameter.

[ochafik]

Looks good, couple of nits + could benefit from more tests

[ochafik]

Would be good to add expectations on resource param to tests/client/test_auth.py similar to https://github.com/modelcontextprotocol/typescript-sdk/pull/638/files#diff-68dc66b14905d1fc01dc142e244a7e13fbdf88062d3a0b426983c333ccdfc9ed

(doesn't look like there's tests for authorize.py or for provider.py yet, not sure how hard they'd be to add)

[ochafik]

Thanks @ihrpr !

The base branch was changed.

[pcarleton]

LGTM!

[dr3s]

Heads up that I'm going to submit a PR imminently to omit the resource parameter when the PRM is not available and the server version is 3-26-2025 or earlier. Just caught up with @pcarleton on the need to retain backwards compatibility for earlier servers.

Whether servers should be able to support more recent protocol versions without the resource parameter is an open question.