You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support RFC 9728 well-known paths with resource components (#2197)
The previous implementation used exact path matching for the well-known
OAuth protected resource metadata endpoint, which only accepted:
/.well-known/oauth-protected-resource
This broke RFC 9728 Section 3.1 compliance for resources with path
components. When a resource is identified as "https://server.com/mcp",
clients must fetch metadata from:
/.well-known/oauth-protected-resource/mcp
But the exact match would return 404, preventing proper OAuth discovery
for MCP servers with path-based resource identifiers.
Changed to prefix matching to support both:
- /.well-known/oauth-protected-resource (base path)
- /.well-known/oauth-protected-resource/mcp (with resource component)
- /.well-known/oauth-protected-resource/resource1 (multi-tenant)
This enables multi-tenant hosting configurations as specified in
RFC 9728 and ensures OAuth discovery works correctly for MCP servers
regardless of their path structure.
Note: The current implementation accepts all paths under the prefix
(e.g., /.well-known/oauth-protected-resource/*). In the future, this
could be tightened by having NewAuthInfoHandler parse the request path,
extract the resource component, and validate it matches the resourceURL
path before returning metadata. This would enforce stricter path
matching while maintaining RFC 9728 compliance.
0 commit comments