[!info] related notes

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

OAuth Dynamic Client Registration（DCR）

一句话定义

DCR（Dynamic Client Registration）是 OAuth 2.0 的动态客户端注册机制：客户端向授权服务器开放的 registration endpoint 提交自己的元数据，服务器按策略登记客户端并返回 client_id 等注册结果。

解决的问题

不必由管理员逐一手动登记客户端。客户端可以通过协议提交 redirect_uris、client_name、支持的 grant/response 类型和客户端认证方法，取得该授权服务器认可的注册记录，然后正常发起 OAuth 登录与用户授权。

典型链路

MCP 客户端
  ├─ 发现授权服务器 registration_endpoint
  ├─ POST 客户端元数据
  ▼
Authorization Server
  ├─ 校验注册策略、回调限制与元数据
  ├─ 存储注册记录
  └─ 返回该服务端分配的 client_id
       ↓
继续 OAuth Authorization Code + PKCE

注册成功只表示该授权服务器接受了这份客户端注册信息，不是用户已经授权，更不是客户端将自动获得数据权限。DCR endpoint 也不必完全匿名开放：服务端可以限制/保护注册。

与 CIMD 的关键边界

• DCR 通常由服务器保存每份客户端注册记录并分配 client_id，注册信息与该 issuer 绑定。
• CIMD 让客户端在自己的 HTTPS URL 发布文档，这个 URL 自身是 client_id；相同元数据可被多个授权服务器解析。
• 在 MCP 2026-07-28 中，DCR 已被标为 deprecated（为旧客户端兼容保留），新客户端优先采用 CIMD/预注册；这不等于 RFC 7591 在所有 OAuth 场景被废止。
• 关闭 DCR 不能自动阻止未知 CIMD 客户端；能否准入由服务端政策决定。

实践判断

如果新做一个公共远程 MCP 连接：优先准备 CIMD，支持已有合作方预注册；确实有旧客户端必须依赖注册端点时，再评估受控 DCR 兼容车道。不要把“DCR 曾经流行”误认为它是当前 MCP 的默认最佳方案。

学习检查

1. DCR 与授权码模式分别发生在什么阶段？
2. 为什么 DCR 分配的 client_id 不应跨 issuer 随意复用？
3. 注册成功能否跳过用户同意？
4. MCP 标记 DCR deprecated 是否意味着所有 OAuth 服务都禁止 DCR？
5. 关闭 DCR 以后，合法 CIMD 客户端是否仍可能请求授权？

参考

• RFC 7591：OAuth 2.0 Dynamic Client Registration
• MCP 2026-07-28 Client Registration