[!info] related notes

• 所属 MOC: mcp-moc
• 前置概念: oauth-client-identity-and-authentication、oauth2
• 并列概念:
• 易混淆概念:
• 关系笔记:

OAuth Client ID Metadata Document（CIMD）

一句话定义

CIMD（Client ID Metadata Document）允许 OAuth 客户端把自己的 HTTPS 元数据文档 URL 直接用作 client_id；授权服务器按该 URL 获取 JSON 元数据，并验证客户端声明的名称、回调地址和其他注册字段。

为什么出现

当一个 Codex / Claude Code 要连接大量彼此独立的 MCP Server 时，如果每个服务器都要求事先人工登记或者运行一次动态注册，集成成本很高。CIMD 使一个稳定、可重用的客户端元数据地址能被多个授权服务器解析。

最小示例

下面是示意文档，并非真实厂商配置：

{
  "client_id": "https://client.example.com/oauth/client.json",
  "client_name": "Example CLI",
  "redirect_uris": ["http://127.0.x.x:3000/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "token_endpoint_auth_method": "none"
}

客户端在请求中使用该 HTTPS URL 作为 client_id；授权服务器获取文档，核对 client_id 与实际 URL 一致、metadata 格式有效，并严格校验使用的 redirect URI。只有通过服务器自己的客户端准入策略，才可能进一步进入用户登录与 consent。

安全不变量

• 元数据可以被读取且字段自洽，不代表官方认证、不代表信任评级、更不代表用户授权。
• 必须防止服务端拉取任意 URL 导致的 SSRF：只接受合理 HTTPS URL、限制解析后的地址、处理 DNS 重绑定与重定向、约束响应大小/超时，并在 HTTP 缓存策略内安全重验。
• 授权服务器应精确校验 client_id URL 与文档字段，限制 callback 到已登记范围；原生 loopback 回调例外依其适用规范处理。
• 公开客户端常声明 token_endpoint_auth_method: none 并使用 PKCE；CIMD 本身不禁止支持具备适用凭据的 confidential client。
• 是否允许任意合法 CIMD、只允许指定 metadata URL，或将未知应用标记给用户，属于服务端准入策略，不是仅靠关掉 DCR 就自动决定。

在 MCP 的位置

MCP 2026-07-28 推荐 CIMD 作为没有预先关系时的客户端注册方式；对于已经有预注册信息的客户端，官方优先级仍首先使用预注册。CIMD 是授权流程之前的 client metadata 发现，不是对 tools/call 发起凭据认证。

学习检查

1. 为什么 CIMD 的 client_id 是 URL，而 DCR 的通常由服务端分配？
2. 服务端成功读取一个 HTTPS JSON 文件后，为什么仍不能断言它属于某个真实厂商？
3. metadata URL 为什么构成 SSRF 风险？
4. 预注册和 CIMD 同时可用时，MCP 推荐优先哪一个？
5. CIMD 与授权码 + PKCE 是先后关系还是替代关系？

参考

• MCP 2026-07-28 Client Registration
• OAuth Client ID Metadata Document 草案（MCP 所采用的 profile）