Skip to content

fix: include transport path in protected resource metadata URL (RFC 9728) - #2665

Closed
arkh-node wants to merge 3 commits into
modelcontextprotocol:mainfrom
arkh-node:fix/1264-resource-url-includes-transport-path
Closed

fix: include transport path in protected resource metadata URL (RFC 9728)#2665
arkh-node wants to merge 3 commits into
modelcontextprotocol:mainfrom
arkh-node:fix/1264-resource-url-includes-transport-path

Conversation

@arkh-node

Copy link
Copy Markdown

$(cat <<'EOF'

Summary

Fixes#1264

The resource field in /.well-known/oauth-protected-resource was set to the
bare resource_server_url (e.g. http://localhost:8000/) instead of the actual
protected endpoint URL (e.g. http://localhost:8000/mcp).

Per RFC 9728 §3, the
resource identifier must match the URL that clients use to access the protected
resource. This caused VS Code Copilot (and other spec-compliant clients) to reject
the server with:

Protected Resource Metadata resource "http://localhost:8000/" does not match
MCP server resolved resource "http://localhost:8000/mcp"

Changes

  • src/mcp/server/lowlevel/server.py: append streamable_http_path to
    resource_server_url before passing it to create_protected_resource_routes
    and build_resource_metadata_url.
  • src/mcp/server/mcpserver/server.py: same fix for sse_path.
  • tests/server/auth/test_protected_resource.py: 4 new tests verifying
    the URL construction and metadata response for /mcp and /sse transport paths.

Tests

python3 -m pytest tests/server/auth/test_protected_resource.py -v
# 18 passed
python3 -m pytest tests/server/mcpserver/auth/ -v -p no:monocle_test_tools
# 44 passed

Note: PR #2189 (same fix, closed 2026-03-05 without merge) was used as reference
for the correct approach.
EOF
)

arkh-nodeand others added 3 commits May 23, 2026 10:02
…endpoint
When a client uses HTTP Basic authentication (RFC 6749 §2.3.1), its
client_id and client_secret arrive in the Authorization header rather
than the request body. ClientAuthenticator already validates Basic auth
correctly for `client_secret_basic` clients, but it failed early with
"Missing client_id" when client_id was absent from form data.
TokenHandler also required client_id in form data for TokenRequest
validation, causing a second failure path.
Changes:
- ClientAuthenticator.authenticate_request: extract client_id from Basic
auth header when not present in form body, before the missing-id check
- TokenHandler.handle: populate client_id from the already-authenticated
client_info when absent from form data, so TokenRequest validates cleanly
Two new tests cover the authorization_code and refresh_token grant flows
with client_id supplied only via Authorization header.
Fixes#1315
Signed-off-by: afischh <afischh@gmail.com>
…728)
Per RFC 9728 §3, the `resource` field in `/.well-known/oauth-protected-resource`
must identify the actual protected endpoint URL — e.g. `http://localhost:8000/mcp`,
not the bare server base `http://localhost:8000/`. Without the path, VS Code Copilot
and other spec-compliant clients reject the server with:
Protected Resource Metadata resource "http://localhost:8000/" does not match
MCP server resolved resource "http://localhost:8000/mcp"
Fix: append `streamable_http_path` / `sse_path` to `resource_server_url` before
passing it to `create_protected_resource_routes` and `build_resource_metadata_url`
in both the lowlevel and mcpserver transports.
Fixes#1264
Signed-off-by: Alex Fisch <afischh@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for freeto 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.

Protected Resource Metadata resource erroneous when setting up authentication on server

1 participant

@arkh-node