Skip to main content
本文档描述 MCP 服务器向 MCP 客户端公布其关联授权服务器的机制，以及 MCP 客户端用于确定授权服务器端点和受支持能力的发现流程。

​
Authorization Server Location

MCP 服务器 MUST 实现 OAuth 2.0 Protected Resource Metadata (RFC9728) 规范，以指示授权服务器的位置。MCP 服务器返回的受保护资源元数据文档 MUST 包含 authorization_servers 字段，且其中至少包含一个授权服务器。 authorization_servers 的具体用法超出本规范范围；实现者应参考 OAuth 2.0 Protected Resource Metadata (RFC9728)，以获取实现细节方面的指导。 实现者应注意，受保护资源元数据文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在 MCP 客户端，客户端应遵循 RFC9728 Section 7.6 “Authorization Servers” 中规定的指导原则。 当 authorization_servers 中列出多个授权服务器时，每一个都是独立的 OAuth 2.0 授权服务器。根据 RFC 6749 Section 2.2，客户端标识符仅对颁发它们的授权服务器唯一。客户端 MUST 为每个授权服务器维护单独的注册状态（客户端凭据、令牌），并且 MUST NOT 假定对一个授权服务器有效的凭据会被另一个授权服务器接受。关于将客户端凭据与颁发它们的授权服务器关联的要求，请参见授权服务器绑定。

​
Protected Resource Metadata Discovery Requirements

MCP 服务器 MUST 实现以下发现机制之一，以向 MCP 客户端提供授权服务器位置信息：
  1. WWW-Authenticate 标头：返回 401 Unauthorized 响应时，在 WWW-Authenticate HTTP 标头的 resource_metadata 中包含资源元数据 URL，如 RFC9728 Section 5.1 所述。
  2. Well-Known URI：按照 RFC9728 的规定，在 well-known URI 上提供元数据。可以是：
    • 位于服务器 MCP 端点的路径：https://example.com/public/mcp 可以在 https://example.com/.well-known/oauth-protected-resource/public/mcp 托管元数据
    • 位于根路径：https://example.com/.well-known/oauth-protected-resource
MCP 客户端 MUST 支持这两种发现机制；当解析后的 WWW-Authenticate 标头中存在资源元数据 URL 时，客户端 MUST 使用该 URL；否则，客户端 MUST 回退为按上面列出的顺序构造并请求 well-known URI。 MCP 客户端 MUST 能够解析 WWW-Authenticate 标头，并对来自 MCP 服务器的 HTTP 401 Unauthorized 响应做出适当处理。 服务器还可以在 WWW-Authenticate 质询中包含 scope 参数，以指示访问资源所需的作用域；作用域语义和相关客户端行为在作用域选择策略部分定义。

​
Authorization Server Metadata Discovery

MCP 使用 RFC 8414 Section 3.1 中定义的默认 oauth-authorization-server well-known URI 后缀来发现授权服务器元数据。MCP 不定义特定于应用的 well-known URI 后缀。 为处理不同的 issuer URL 格式，并确保同时与 OAuth 2.0 Authorization Server Metadata 和 OpenID Connect Discovery 1.0 规范互操作，MCP 客户端在发现授权服务器元数据时 MUST 尝试多个 well-known 端点。 该发现方法基于用于 OAuth 2.0 Authorization Server Metadata 发现的 RFC 8414 Section 3.1 “Authorization Server Metadata Request”，以及用于 OpenID Connect Discovery 1.0 互操作的 RFC 8414 Section 5 “Compatibility Notes”。 对于带路径组件的 issuer URL（例如 https://auth.example.com/tenant1），客户端 MUST 按以下优先级顺序尝试端点：
  1. 带路径插入的 OAuth 2.0 Authorization Server Metadata： https://auth.example.com/.well-known/oauth-authorization-server/tenant1
  2. 带路径插入的 OpenID Connect Discovery 1.0： https://auth.example.com/.well-known/openid-configuration/tenant1
  3. 路径追加形式的 OpenID Connect Discovery 1.0： https://auth.example.com/tenant1/.well-known/openid-configuration
对于不带路径组件的 issuer URL（例如 https://auth.example.com），客户端 MUST 尝试：
  1. OAuth 2.0 Authorization Server Metadata： https://auth.example.com/.well-known/oauth-authorization-server
  2. OpenID Connect Discovery 1.0： https://auth.example.com/.well-known/openid-configuration
检索到元数据文档后，MCP 客户端 MUST 按照 RFC8414 Section 3.3 或 OpenID Connect Discovery Section 4.3 的要求验证该文档：文档中的 issuer 值 MUST 与用于构造 well-known URL 的 issuer 标识符完全相同。如果二者不同，客户端 MUST NOT 使用该元数据。例如，从 https://attacker.example/.well-known/oauth-authorization-server 获取且包含 "issuer": "https://honest.example" 的文档 MUST 被拒绝。

​
Sequence Diagram

下图概述了一个示例流程：