SEP-985：使 OAuth 2.0 受保护资源元数据与 RFC 9728 保持一致

社区译文；来源： MCP 29affa6b

摘要

本提案使 MCP 规范对 OAuth 2.0 受保护资源元数据的处理与 RFC 9728 保持一致。

目前，MCP 规范要求在返回 401 Unauthorized 时使用 HTTP WWW-Authenticate 标头来指明受保护资源元数据的位置。但是，RFC 9728 第 5 节指出：

“受保护资源可以（MAY）使用 RFC 9110 所述的 WWW-Authenticate HTTP 响应标头字段，向客户端返回其受保护资源元数据的 URL。”

这表明，可以在保持符合 RFC 的同时，让 MCP 规范更加灵活。

理由

许多大型、动态、多租户环境依赖独立于后端资源服务器的集中式身份验证服务。在这类部署中，由于关注点分离和基础设施复杂，从后端服务注入 WWW-Authenticate 标头并非易事。

在这些场景中，允许通过 well-known URL 发现元数据，为更容易采用 MCP 提供了切实可行的路径。如果只允许使用标头，会给组件之间带来很大的协调开销，尤其是在动态创建和销毁数百或数千个 MCP 实例时。此外，如果存在特定的托管 MCP 服务器，在整个集中式系统中采用标头也会增加大量开销。

这会增加客户端的复杂度，因为客户端现在必须实现探测元数据端点的逻辑；但它能降低服务器部署的阻力，并可能促进更广泛的采用。其权衡如下：

服务器开发者的优点：避免复杂的标头注入；简化分布式环境中的集成。

客户端开发者的缺点：当标头不存在时，客户端必须回退到元数据发现逻辑，从而增加客户端复杂度。

提议状态

将 MCP 规范更新为：

客户端 MUST 解析并处理 WWW-Authenticate 标头；如果该标头不存在，则回退到探测元数据。
服务器 SHOULD 返回 WWW-Authenticate 标头。

略微偏离 RFC 的原因： 对 WWW-Authenticate 采用 SHOULD 而不是 MAY，可以更容易地支持其他特性，例如增量授权（例如，你请求调用一个工具，但需要额外 scope，并收到一个指明这些 scope 的 WWW-Authenticate challenge）。

根据以上内容，更新后的流程如下：

• 在没有 token 的情况下尝试 MCP 请求。
• 如果收到 401 Unauthorized 响应：检查 WWW-Authenticate 标头。如果标头存在并包含 resource_metadata 参数，则使用该参数定位资源元数据。
• 如果标头不存在或不包含 resource_metadata，则回退为请求 /.well-known/oauth-protected-resource。

此更改在不移除现有能力的情况下，支持更灵活的部署模型。

  sequenceDiagram
    participant C as 客户端
    participant M as MCP 服务器（资源服务器）
    participant A as 授权服务器

    Note over C: 尝试未经身份验证的 MCP 请求
    C->>M: 不带 token 的 MCP 请求
    M-->>C: HTTP 401 Unauthorized（可能包含 WWW-Authenticate 标头）

    alt 标头包含 resource_metadata
        Note over C: 从标头提取 resource_metadata URL
        C->>M: GET resource_metadata URI
        M-->>C: 包含授权服务器 URL 的资源元数据
    else 标头中没有 resource_metadata
        Note over C: 回退到元数据探测
        C->>M: GET /.well-known/oauth-protected-resource
        alt 找到元数据
            M-->>C: 包含授权服务器 URL 的资源元数据
        else 未找到元数据
            Note over C: 中止或使用预配置值
        end
    end

    Note over C: 验证资源服务器元数据，<br />构造授权服务器元数据 URL

    C->>A: GET /.well-known/oauth-authorization-server
    A-->>C: 授权服务器元数据

    Note over C,A: 在此执行 OAuth 2.1 授权流程

    C->>A: token 请求
    A-->>C: access token

    C->>M: 带 access token 的 MCP 请求
    M-->>C: MCP 响应
    Note over C,M: 使用有效 token 继续 MCP 通信

向后兼容性

本提案完全向后兼容。

它保留了对 WWW-Authenticate 标头的支持（规范中已经存在），并引入使用 .well-known 元数据路径的回退机制；该路径已在 MCP 中定义为 MUST 支持的位置。

已支持元数据探测的客户端将获得更好的互操作性。如果服务器无法实际发送 WWW-Authenticate 标头，则不要求其发送；但仍鼓励这样做，以降低客户端复杂度并支持未来扩展。