客户端注册

MCP 支持三种客户端注册机制。请根据你的场景进行选择：

客户端 ID 元数据文档：当客户端与服务端没有预先建立关系时（最常见）
预注册：当客户端与服务端已有既存关系时
动态客户端注册：用于向后兼容或特定需求

支持所有选项的客户端 SHOULD（应该）使用以下优先级顺序：

如果客户端持有服务端的预注册客户端信息，则使用该信息
如果授权服务器表明支持客户端 ID 元数据文档（通过 OAuth Authorization Server Metadata 中的 client_id_metadata_document_supported），则使用客户端 ID 元数据文档
如果授权服务器支持动态客户端注册（通过 OAuth Authorization Server Metadata 中的 registration_endpoint），则将其作为回退方案
如果没有任何其他选项可用，则提示用户输入客户端信息

客户端 ID 元数据文档

MCP 客户端和授权服务器 SHOULD（应该）支持 OAuth Client ID Metadata Document 中规定的 OAuth 客户端 ID 元数据文档，用于客户端注册。

该方法使客户端能够使用 HTTPS URL 作为客户端标识符，该 URL 指向一个包含客户端元数据的 JSON 文档。这解决了服务端与客户端没有预先建立关系的常见 MCP 场景。

实现要求

支持客户端 ID 元数据文档的 MCP 实现 MUST（必须）遵循 OAuth Client ID Metadata Document 中规定的要求。关键要求包括：

对于 MCP 客户端：

客户端 MUST（必须）按照 RFC 要求将元数据文档托管在 HTTPS URL 上
client_id URL MUST（必须）使用 "https" 方案并包含路径组件，例如 https://example.com/client.json
元数据文档 MUST（必须）至少包含以下属性：client_id、client_name、redirect_uris
客户端 MUST（必须）确保元数据中的 client_id 值与文档 URL 完全一致
客户端 MAY（可以）使用 private_key_jwt 进行客户端认证（例如，用于向 token endpoint 发起的请求），并按照 Client ID Metadata Document 第 6.2 节所述配置相应的 JWKS

对于授权服务器：

遇到 URL 格式的 client_ids 时 SHOULD（应该）获取元数据文档
MUST（必须）验证所获取文档的 client_id 与该 URL 完全一致
SHOULD（应该）遵循 HTTP 缓存头缓存元数据
MUST（必须）将授权请求中提交的重定向 URI 与元数据文档中的重定向 URI 进行校验
MUST（必须）验证文档结构为有效 JSON 且包含必需字段
SHOULD（应该）遵循 Client ID Metadata Document 第 6 节以及 Client ID Metadata Document Security 中的安全注意事项

元数据文档示例

json

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

客户端 ID 元数据文档流程

下图展示了使用客户端 ID 元数据文档时的完整流程：

sequenceDiagram
    participant User
    participant Client as MCP Client
    participant Server as Authorization Server
    participant Metadata as Metadata Endpoint<br/>(Client's HTTPS URL)
    participant Resource as MCP Server

    Note over Client,Metadata: Client hosts metadata at<br/>https://app.example.com/oauth/metadata.json

    User->>Client: Initiates connection to MCP Server
    Client->>Server: Authorization Request<br/>client_id=https://app.example.com/oauth/metadata.json<br/>redirect_uri=http://localhost:3000/callback

    Server->>User: Authentication prompt
    User->>Server: Provides credentials
    Note over Server: Authenticates user

    Note over Server: Detects URL-formatted client_id

    Server->>Metadata: GET https://app.example.com/oauth/metadata.json
    Metadata-->>Server: JSON Metadata Document<br/>{client_id, client_name, redirect_uris, ...}

    Note over Server: Validates:<br/>1. client_id matches URL<br/>2. redirect_uri in allowed list<br/>3. Document structure valid<br/>4. (Optional) Domain allowed via trust policy

    alt Validation Success
        Server->>User: Display consent page with client_name
        User->>Server: Approves access
        Server->>Client: Authorization code via redirect_uri
        Client->>Server: Exchange code for token<br/>client_id=https://app.example.com/oauth/metadata.json
        Server-->>Client: Access token
        Client->>Resource: MCP requests with access token
        Resource-->>Client: MCP responses
    else Validation Failure
        Server->>User: Error response<br/>error=invalid_client or invalid_request
    end

    Note over Server: Cache metadata for future requests<br/>(respecting HTTP cache headers)

声明 CIMD 支持

授权服务器通过在其 OAuth 授权服务器元数据中包含以下属性，来声明其支持使用客户端 ID 元数据文档的客户端：

json

{
  "client_id_metadata_document_supported": true
}

MCP 客户端 SHOULD（应该）检查此能力，并在不可用时 MAY（可以）回退到动态客户端注册或预注册。

预注册

MCP 客户端 SHOULD（应该）支持静态客户端凭据选项，例如通过预注册流程提供的凭据。这可以是：

硬编码一个客户端 ID（以及适用的客户端凭据），专门供 MCP 客户端在与该授权服务器交互时使用，或
向用户展示一个 UI，允许他们在自行注册 OAuth 客户端后（例如，通过由服务器托管的配置界面）输入这些详细信息。

动态客户端注册

WARNING

动态客户端注册已弃用。新实现应改用客户端 ID 元数据文档。此选项仍然保留，以向后兼容不支持客户端 ID 元数据文档的授权服务器。

MCP 客户端和授权服务器 MAY（可以）支持 OAuth 2.0 动态客户端注册协议 RFC7591，以允许 MCP 客户端在无需用户交互的情况下获取 OAuth 客户端 ID。此选项的纳入是为了向后兼容早期版本的 MCP 授权规范。

应用类型与重定向 URI 约束

当授权服务器支持 OpenID Connect (OIDC) 和动态客户端注册时，它们可能会根据 OpenID Connect Dynamic Client Registration 1.0 中定义的 application_type 参数，对重定向 URI 施加额外约束。

MCP 客户端 MUST（必须）在动态客户端注册期间指定适当的 application_type。在 OIDC 下省略该参数会默认为 "web"，这可能与原生风格的重定向 URI 冲突；非 OIDC 服务器会安全地忽略该参数。

原生应用（桌面应用、移动应用、 CLI 工具，以及通过 localhost 访问的本地托管 Web 应用）SHOULD（应该）使用 application_type: "native"
Web 应用（由非本地主机提供服务的远程基于浏览器的应用）SHOULD（应该）使用 application_type: "web"

当授权服务器实现 OIDC 时，MCP 客户端 MUST（必须）准备好处理因重定向 URI 约束而导致的注册失败。当注册请求被拒绝时，客户端 SHOULD（应该）向用户或开发者呈现有意义的错误。客户端 MAY（可以）使用调整后的 application_type 或符合授权服务器对给定应用类型要求的重定向 URI 重试注册。

授权服务器绑定

使用预注册凭据，或持久化通过动态客户端注册获得的客户端凭据的客户端，MUST（必须）将这些凭据与签发它们的特定授权服务器关联，并以授权服务器的 issuer 标识符为键。当授权服务器发生变化时（通过更新后的受保护资源元数据检测到），客户端 MUST NOT（不得）复用来自不同授权服务器的客户端凭据，并且 MUST（必须）向新的授权服务器重新注册。

预注册凭据本质上特定于某个授权服务器。如果受保护资源元数据所指示的授权服务器不再与凭据注册时所对应的授权服务器匹配，客户端 SHOULD（应该）呈现错误，而不是静默尝试使用不匹配的凭据。

基于客户端 ID 元数据文档的客户端 ID 可跨授权服务器移植，因为它们是由授权服务器按需解析的自托管 HTTPS URL。当授权服务器发生变化时，无需重新注册。