授权服务器发现

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

授权服务器位置

MCP 服务端 MUST（必须）实现 OAuth 2.0 Protected Resource Metadata（RFC9728）规范，以指明授权服务器的位置。MCP 服务端返回的 Protected Resource Metadata 文档 MUST（必须）包含 authorization_servers 字段，其中至少包含一个授权服务器。

authorization_servers 的具体用法超出本规范的范围；实现者应查阅 OAuth 2.0 Protected Resource Metadata（RFC9728）以获取实现细节方面的指导。

实现者应注意，Protected Resource Metadata 文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在于 MCP 客户端，遵循 RFC9728 Section 7.6 "Authorization Servers" 中规定的准则。

当 authorization_servers 中列出多个授权服务器时，每一个都是独立的 OAuth 2.0 授权服务器。与 RFC 6749 Section 2.2 一致，客户端标识符对于签发它的授权服务器而言是唯一的。客户端 MUST（必须）为每个授权服务器维护独立的注册状态（客户端凭据、令牌），并且 MUST NOT（不得）假设对某个授权服务器有效的凭据会被另一个授权服务器接受。关于将客户端凭据与签发它们的授权服务器相关联的要求，请参见授权服务器绑定。

Protected Resource Metadata 发现要求

MCP 服务端 MUST（必须）实现以下发现机制之一，以向 MCP 客户端提供授权服务器位置信息：

WWW-Authenticate Header：在返回 401 Unauthorized 响应时，在 WWW-Authenticate HTTP 头中的 resource_metadata 下包含资源元数据 URL，如 RFC9728 Section 5.1 所述。
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（必须）回退到按上述顺序构造并请求 well-known URI。

MCP 客户端 MUST（必须）能够解析 WWW-Authenticate 头，并适当地响应来自 MCP 服务端的 HTTP 401 Unauthorized 响应。

服务端还可以在 WWW-Authenticate 质询中包含 scope 参数，以指示访问该资源所需的作用域；作用域语义及相关的客户端行为在作用域选择策略一节中定义。

授权服务器元数据发现

MCP 使用 RFC 8414 Section 3.1 中定义的默认 oauth-authorization-server well-known URI 后缀进行授权服务器元数据发现。MCP 不定义特定于应用的 well-known URI 后缀。

为处理不同的签发者 URL 格式，并确保与 OAuth 2.0 Authorization Server Metadata 和 OpenID Connect Discovery 1.0 两种规范的互操作性，MCP 客户端在发现授权服务器元数据时 MUST（必须）尝试多个 well-known 端点。

该发现方法基于 RFC 8414 Section 3.1 "Authorization Server Metadata Request"（用于 OAuth 2.0 Authorization Server Metadata 发现）以及 RFC 8414 Section 5 "Compatibility Notes"（用于 OpenID Connect Discovery 1.0 互操作性）。

对于带路径组件的签发者 URL（例如 https://auth.example.com/tenant1），客户端 MUST（必须）按以下优先级顺序尝试端点：

带路径插入的 OAuth 2.0 Authorization Server Metadata： https://auth.example.com/.well-known/oauth-authorization-server/tenant1
带路径插入的 OpenID Connect Discovery 1.0： https://auth.example.com/.well-known/openid-configuration/tenant1
路径追加的 OpenID Connect Discovery 1.0： https://auth.example.com/tenant1/.well-known/openid-configuration

对于不带路径组件的签发者 URL（例如 https://auth.example.com），客户端 MUST（必须）尝试：

OAuth 2.0 Authorization Server Metadata： https://auth.example.com/.well-known/oauth-authorization-server
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 的签发者标识符完全相同。如果二者不同，客户端 MUST NOT（不得）使用该元数据。例如，从 https://attacker.example/.well-known/oauth-authorization-server 获取的、包含 "issuer": "https://honest.example" 的文档 MUST（必须）被拒绝。

时序图

以下图表展示了一个示例流程：

sequenceDiagram
    participant C as Client
    participant M as MCP Server (Resource Server)
    participant A as Authorization Server

    Note over C: Attempt unauthenticated MCP request
    C->>M: MCP request without token
    M-->>C: HTTP 401 Unauthorized (may include WWW-Authenticate header)

    alt Header includes resource_metadata
        Note over C: Extract resource_metadata URL from header
        C->>M: GET resource_metadata URI
        M-->>C: Resource metadata with authorization server URL
    else No resource_metadata in header
        Note over C: Fallback to well-known URI probing
        Note over M: _Not applicable if the MCP server is at the root_
        C->>M: GET /.well-known/oauth-protected-resource/mcp
        alt Sub-path metadata found
            M-->>C: Resource metadata with authorization server URL
        else Sub-path not found
            C->>M: GET /.well-known/oauth-protected-resource
            alt Root metadata found
                M-->>C: Resource metadata with authorization server URL
            else Root metadata not found
                Note over C: Abort or use pre-configured values
            end
        end
    end

    Note over C: Validate RS metadata,<br />build AS metadata URL

    C->>A: GET Authorization server metadata endpoint
    Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order
    A-->>C: Authorization server metadata

    Note over C,A: OAuth 2.1 authorization flow happens here

    C->>A: Token request
    A-->>C: Access token

    C->>M: MCP request with access token
    M-->>C: MCP response
    Note over C,M: MCP communication continues with valid token

授权服务器发现

授权服务器位置

Protected Resource Metadata 发现要求

授权服务器元数据发现

时序图

友情链接