Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#1,298 1 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

@DaleSeo 已经在做这个了。

开始于 2026年9月26日。

  • #1302 来自 @DaleSeo —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
74/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
api, authentication, security

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Rust
星标
4k
派生
654
平均合并
4 天 3 小时
30 天内合并 PR
40

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/rust-sdk 的其他 Issue

查看 modelcontextprotocol/rust-sdk 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。