Skip to content

[WIP][POC] Update logic for constructing protected resource metadata URL to include the resource's path component, for compatibility with Oauth RFCs #1179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

smurching
Copy link

@smurching smurching commented Jul 21, 2025

Motivation and Context

Update logic for constructing the protected resource metadata URL for an MCP server to include the path component of the resource being accessed, as per section 3.1 of Oauth RFC 9728:

3.1. Protected Resource Metadata Request

A protected resource metadata document MUST be queried using an HTTP
GET request at the previously specified URL.

The consumer of the metadata would make the following request when
the resource identifier is https://resource.example.com and the well-
known URI path suffix is oauth-protected-resource to obtain the
metadata, since the resource identifier contains no path component:

 GET /.well-known/oauth-protected-resource HTTP/1.1
 Host: resource.example.com

If the resource identifier value contains a path or query component,
any terminating slash (/) following the host component MUST be
removed before inserting /.well-known/ and the well-known URI path
suffix between the host component and the path and/or query
components. The consumer of the metadata would make the following
request when the resource identifier is https://resource.example.com/
resource1 and the well-known URI path suffix is oauth-protected-
resource to obtain the metadata, since the resource identifier
contains a path component:

 GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
 Host: resource.example.com

Using path components enables supporting multiple resources per host.
This is required in some multi-tenant hosting configurations. This
use of .well-known is for supporting multiple resources per host;
unlike its use in [RFC8615], it does not provide general information
about the host.

To avoid breaking changes, we first attempt RFC-compliant behavior, e.g. for https://api.example.com/mcp, first try to query a PRM endpoint at https://api.example.com/.well-known/oauth-protected-resource/mcp. If that fails, we then fall back to querying https://api.example.com/.well-known/oauth-protected-resource (existing behavior, excluding the /mcp path component)

How Has This Been Tested?

Updated unit tests - TODO test this against some real example servers

Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@smurching smurching requested review from a team as code owners July 21, 2025 21:33
@smurching smurching requested review from pcarleton and Kludex July 21, 2025 21:33
Signed-off-by: Sid Murching <[email protected]>
@smurching smurching changed the title [POC] Update logic for constructing protected resource metadata URL to include the resource's path component, for compatibility with Oauth RFCs [WIP][POC] Update logic for constructing protected resource metadata URL to include the resource's path component, for compatibility with Oauth RFCs Jul 21, 2025
Signed-off-by: Sid Murching <[email protected]>
await self._handle_protected_resource_response(discovery_response)
break # Success, stop trying other URLs
elif discovery_response.status_code != 404:
break # Non-404 error, stop trying
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice we may want to keep retrying on other types of errors too, just to be safe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant