[!info] related notes

• 所属 MOC: mcp-moc
• 相关概念: oauth-client-id-metadata-document、oauth-dynamic-client-registration、oauth-client-identity-and-authentication、oauth-authorization-code-pkce
• 易混淆概念:
• 相关资源:

OAuth Client Registration：预注册、CIMD 与 DCR

范围

这三种方案都发生在 OAuth 用户授权之前，负责让 Authorization Server 知道某个客户端的 client_id、允许的回调和注册元数据。它们不能代替用户登录、consent、PKCE 或 Bearer Access Token。

为什么要一起理解

当 Codex 或 Claude Code 连接一个此前不认识它的 MCP Server 时，服务端需要一种方法识别客户端元数据，但未必需要“用客户端密钥证明软件来自官方”。不同注册机制解决的是登记与分发方式的问题。

三种方案

机制	获取 client_id	元数据在哪里	更适合
Pre-registration（预注册）	由服务端事先分配/约定	服务端已有记录	双方预先合作、配置固定
CIMD	客户端的 HTTPS metadata URL 本身	客户端托管；服务端安全抓取/缓存	大量未知服务器、跨服务器复用
DCR	客户端向 registration endpoint POST，服务器返回 client_id	服务器保存注册记录	旧协议兼容、特定动态注册需求

MCP 2026-07-28 的客户端选择优先级

1. 如果已经有对这个 issuer 有效的预注册信息，先使用预注册。
2. 否则，如果 Authorization Server 声明支持 CIMD，采用 CIMD。
3. 否则，如果开放注册 endpoint，才尝试 DCR。
4. 前面都不支持，才考虑提示用户手动提供客户端注册信息。

这是推荐优先级，不保证任意产品/版本都实现所有分支；实际还受客户端回调、token endpoint 认证方法等兼容条件影响。

信任与安全区别

• Registration 不等于 Authentication：上传或读取了元数据不等于证明软件厂商身份。
• Registration 不等于 Consent：成功登记没有赋予用户数据权限。
• CIMD 不等于开放准入：授权服务器可以按本地 policy 限定允许的客户端标识；关闭 DCR 也不会自动屏蔽陌生 CIMD URL。
• DCR/预注册的客户端信息按 issuer 绑定：不能把一个授权服务器分配的 client_id 或凭据拿去另一个服务器使用；CIMD 的 URL 则可以被多个服务器解析。
• DCR 在 MCP 的 2026 规范中被弃用并保留兼容，这不是说整个 OAuth 世界已经删除 RFC 7591。

最小决策例子

为一个新的 Hosted MCP Server 设计客户端接入：支持 CIMD 并进行 URL 抓取安全校验；为已知、需要固定配置的客户端维护预注册；先不开放 DCR，除非已知客户端兼容性确实要求。另行确定 admission policy，不要把“CIMD 支持”偷换为“任何陌生应用都可信”。

学习检查

1. 为什么一个注册方案不能代替 OAuth 用户授权？
2. 某客户端有预注册 client_id 时，MCP 推荐先用哪条路径？
3. 哪种方案天然需要从外部 HTTPS URL 拉元数据，会带来什么风险？
4. 为什么 DCR 注册数据需要跟 issuer 绑定？
5. 关闭 DCR 后，为什么仍需单独设计客户端准入策略？

参考

• MCP Client Registration 2026-07-28
• RFC 7591：DCR