> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.developerdoc.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 授权服务器发现

<div id="enable-section-numbers" />

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

## Authorization Server Location

MCP 服务器 **MUST** 实现 OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) 规范，以指示授权服务器的位置。MCP 服务器返回的受保护资源元数据文档 **MUST** 包含 `authorization_servers` 字段，且其中至少包含一个授权服务器。

`authorization_servers` 的具体用法超出本规范范围；实现者应参考 OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))，以获取实现细节方面的指导。

实现者应注意，受保护资源元数据文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在 MCP 客户端，客户端应遵循 [RFC9728 Section 7.6 "Authorization Servers"](https://datatracker.ietf.org/doc/html/rfc9728#name-authorization-servers) 中规定的指导原则。

当 `authorization_servers` 中列出多个授权服务器时，每一个都是独立的 OAuth 2.0 授权服务器。根据 [RFC 6749 Section 2.2](https://datatracker.ietf.org/doc/html/rfc6749#section-2.2)，客户端标识符仅对颁发它们的授权服务器唯一。客户端 **MUST** 为每个授权服务器维护单独的注册状态（客户端凭据、令牌），并且 **MUST NOT** 假定对一个授权服务器有效的凭据会被另一个授权服务器接受。关于将客户端凭据与颁发它们的授权服务器关联的要求，请参见[授权服务器绑定](/specification/draft/basic/authorization/client-registration#authorization-server-binding)。

## Protected Resource Metadata Discovery Requirements

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

1. **WWW-Authenticate 标头**：返回 `401 Unauthorized` 响应时，在 `WWW-Authenticate` HTTP 标头的 `resource_metadata` 中包含资源元数据 URL，如 [RFC9728 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9728#name-www-authenticate-response) 所述。

2. **Well-Known URI**：按照 [RFC9728](https://datatracker.ietf.org/doc/html/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` 参数，以指示访问资源所需的作用域；作用域语义和相关客户端行为在[作用域选择策略](/specification/draft/basic/authorization#scope-selection-strategy)部分定义。

## Authorization Server Metadata Discovery

MCP 使用 [RFC 8414 Section 3.1](https://datatracker.ietf.org/doc/html/rfc8414#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"](https://datatracker.ietf.org/doc/html/rfc8414#section-3.1)，以及用于 OpenID Connect Discovery 1.0 互操作的 [RFC 8414 Section 5 "Compatibility Notes"](https://datatracker.ietf.org/doc/html/rfc8414#section-5)。

对于带路径组件的 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](https://datatracker.ietf.org/doc/html/rfc8414#section-3.3) 或 [OpenID Connect Discovery Section 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation) 的要求验证该文档：文档中的 `issuer` 值 **MUST** 与用于构造 well-known URL 的 issuer 标识符完全相同。如果二者不同，客户端 **MUST NOT** 使用该元数据。例如，从 `https://attacker.example/.well-known/oauth-authorization-server` 获取且包含 `"issuer": "https://honest.example"` 的文档 **MUST** 被拒绝。

## Sequence Diagram

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

```mermaid theme={null}
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
```