RFC 9728 §3.3 Resource Identifier Validation Fails When MCP Server Is Behind a Gateway #2760

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

RFC 9728 §3.3 Resource Identifier Validation Fails When MCP Server Is Behind a Gateway

When an MCP client connects to a third-party OAuth-protected MCP server through a gateway or intermediary, the RFC 9728 §3.3 resource identifier validation fails, making it difficult to remain spec-compliant.

The issue arises because the gateway URL and the upstream MCP server URL diverge at the validation step. Here's the flow per spec:

1. Client sends a request to the MCP server via the gateway URL — no token for the upstream MCP server (only a gateway token, if applicable).
2. Server responds with 401 and a WWW-Authenticate header containing the resource_metadata URL.
3. Client fetches the Protected Resource Metadata from the resource_metadata URL.
4. Client validates that the resource field matches the URL used in step 1.
5. ❌ The resource field returned by the upstream MCP server does not match the gateway URL — validation fails per RFC 9728 §3.3.

How are others handling this when a gateway proxies requests to an upstream MCP server?

Two approaches I can see:

• Gateway-side rewriting — The gateway rewrites the WWW-Authenticate header, replacing the upstream MCP server's URL with its own. It also rewrites the response body of the /.well-known/ route accordingly to be the GW URL for the resource field.
• Client-side leniency — Skip the validation failure on the client, but this means deviating from the spec.
  Neither feels clean. Curious what patterns others are using here.
• Maybe spec updates — Should there be anything on the MCP spec to account for cases where there is a GW?