Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

OAuth discovery rejects cross-origin resource_metadata from WWW-Authenticate, breaking centralized PRM (SEP-985) deployments

Open
  • Is something wrong?
#1,298 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 3 days

@DaleSeo is already working on this.

Since Sep 26, 2026.

  • #1302 by @DaleSeo — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
api, authentication, security

Research direction

Start in crates/rmcp/src/transport/auth.rs at AuthorizationManager::resolve_resource_metadata_url, then trace discover_metadata and the OAuthState discovery flow. Reproduce the three-server cross-origin topology described in the issue and inspect the existing is_disallowed_metadata_host handling. Done means a permitted cross-origin resource_metadata URL is fetched, its authorization_servers value is used, and disallowed metadata hosts remain blocked.

Written by the indexing model from the issue text.

Description

bug P1 ready for work T-security T-transport

Describe the bug
AuthorizationManager::resolve_resource_metadata_url (crates/rmcp/src/transport/auth.rs) unconditionally discards a resource_metadata URL from a WWW-Authenticate challenge when it is not same-origin (scheme+host+port) with the MCP resource:

https://github.com/modelcontextprotocol/rust-sdk/blob/main/crates/rmcp/src/transport/auth.rs

fn resolve_resource_metadata_url(value: &str, base_url: &Url) -> Option<Url> {
    ...
    if Self::is_same_origin_resource_metadata_url(base_url, &url) {
        Some(url)
    } else {
        warn!("rejecting resource metadata URL `{url}` because it is not same-origin with `{base_url}`");
        None
    }
}

This check was introduced in #935 (SSRF hardening) and is still present, unchanged and with no opt-out, on main today.

SEP-985 (tracked in #517, closed as implemented) explicitly asks the SDK to support protected-resource-metadata discovery via the resource_metadata parameter in the WWW-Authenticate challenge. That parameter is designed to point at a centralized protected-resource-metadata (PRM) endpoint, which is commonly on a different origin than the MCP resource itself — one PRM host serving metadata for many resource servers, each of which then names its own (also possibly different-origin) authorization server. The same-origin check added in #935 rejects exactly this shape unconditionally, before the authorization_servers value is ever read. There is currently no way to opt into accepting a cross-origin resource_metadata pointer — no builder method, no flag, nothing in AuthorizationManager or OAuthState addresses this specific check.

To Reproduce
Steps to reproduce the behavior:

  1. Stand up a resource server that returns 401 with WWW-Authenticate: Bearer resource_metadata="<url on a different origin than the resource>".
  2. Have that URL serve valid protected-resource metadata naming an authorization_servers entry (on any origin).
  3. Call AuthorizationManager::discover_metadata() (or the equivalent OAuthState discovery flow) against the resource.
  4. Observe that resolve_resource_metadata_url logs rejecting resource metadata URL ... because it is not same-origin and discovery falls through without ever fetching the PRM document or the authorization server metadata.

A self-contained, dependency-free Python reproducer using three loopback-only mock servers (resource / centralized PRM / authorization server) that mirrors this exact topology is available here: https://github.com/openai/codex/issues/42427#issuecomment-5519770828

A real-world case with no mocks: https://api.anthropic.com/v1/design/mcp advertises resource_metadata at https://api.anthropic.com/v1/design/.well-known/oauth-protected-resource, which in turn names https://claude.ai/v1/design/mcp as the authorization server — a different origin from the MCP resource.

Expected behavior
The resource_metadata URL should be followed regardless of origin (subject to the same SSRF allowlist/denylist already applied to authorization-server metadata URLs, e.g. is_disallowed_metadata_host), so that a legitimate centralized PRM host — the deployment shape SEP-985 was written to support — resolves its authorization_servers and completes discovery, instead of being discarded unconditionally.

Logs

[rmcp] warn: rejecting resource metadata URL `https://<prm-host>/.well-known/oauth-protected-resource` because it is not same-origin with `https://<resource-host>/mcp`

Downstream effect in a consuming client (openai/codex), also blocked by this: https://github.com/openai/codex/issues/42427

Additional context

  • This is blocking OAuth login in openai/codex, which uses this SDK for its MCP OAuth client. Claude Code and Qwen Code both complete OAuth against the api.anthropic.com/claude.ai example above; Codex cannot, purely because this SDK never reaches the point of reading authorization_servers.
  • Suggested fix: rather than a binary same-origin requirement on the resource_metadata URL itself, apply the same SSRF allowlist/denylist already used for authorization-server metadata URLs (is_disallowed_metadata_host) to the resolved resource_metadata URL as well. That preserves the SSRF protection #935 was added for while allowing the legitimate cross-origin PRM case.
Dominant language
Rust
Stars
4k
Forks
654
Avg merge
4d 2h
Merged PRs (30d)
40

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/rust-sdk

All issues in modelcontextprotocol/rust-sdk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.