规范
规范
概述
授权
授权服务器发现

授权服务器发现

社区译文；来源： MCP 80041ab0

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

授权服务器位置

MCP 服务器 MUST 实现 OAuth 2.0 受保护资源元数据（RFC9728 ）规范，以指明授权服务器的位置。MCP 服务器返回的受保护资源元数据文档 MUST 包含 authorization_servers 字段，其中至少列出一个授权服务器。

authorization_servers 的具体用法超出本规范范围；实现者应参阅 OAuth 2.0 受保护资源元数据（RFC9728 ），了解实现细节的相关指导。

实现者应注意，受保护资源元数据文档可以定义多个授权服务器。由 MCP 客户端负责选择要使用的授权服务器，并遵循 RFC9728 第 7.6 节“Authorization Servers” 中规定的指导。

当 authorization_servers 中列出多个授权服务器时，每一个都是独立的 OAuth 2.0 授权服务器。根据 RFC 6749 第 2.2 节 ，客户端标识符仅在签发它的授权服务器内唯一。客户端 MUST 为每个授权服务器分别维护注册状态（客户端凭据、令牌），并且 MUST NOT 假定对某个授权服务器有效的凭据会被另一个授权服务器接受。有关将客户端凭据与签发它们的授权服务器关联起来的要求，请参阅授权服务器绑定 。

受保护资源元数据发现要求

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

  1. WWW-Authenticate Header：返回 401 Unauthorized 响应时，按照 RFC9728 第 5.1 节 的说明，在 WWW-Authenticate HTTP Header 的 resource_metadata 参数中包含资源元数据 URL。

  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 Header 中存在资源元数据 URL 时使用该 URL；否则，客户端 MUST 按上述顺序构造并请求 well-known URI。

MCP 客户端 MUST 能够解析 WWW-Authenticate Header，并对 MCP 服务器返回的 HTTP 401 Unauthorized 响应进行适当处理。

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

授权服务器元数据发现

MCP 使用 RFC 8414 第 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 端点。

该发现方法以 RFC 8414 第 3.1 节“Authorization Server Metadata Request” 规定的 OAuth 2.0 Authorization Server Metadata 发现流程，以及 RFC 8414 第 5 节“Compatibility Notes” 规定的 OpenID Connect Discovery 1.0 互操作方式为基础。

对于包含路径组件的 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 第 3.3 节 或 OpenID Connect Discovery 第 4.3 节 的要求进行验证：文档中的 issuer 值 MUST 与用于构造 well-known URL 的 issuer 标识符完全相同。如果两者不同，客户端 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
授权安全注意事项