CIMD：把 OAuth Client ID 变成一张网上身份卡

假设一位客人来到门口。

门卫会问：

你是谁？资料在哪里？怎么证明你不是冒牌货？

在 OAuth 中：

• 客人是 OAuth Client；
• 门卫是 Authorization Server；
• CIMD 就是 Client 放在网上的一张身份卡。

一句话理解 CIMD

CIMD 全名是 Client ID Metadata Document。

它最特别的地方是：

client_id 不再只是一个编号，而是一个 HTTPS 网址。

例如：

https://chatgpt.com/oauth/client.json

Authorization Server 收到这个 client_id 后，会访问该网址，读取 Client 的身份资料：

🤖 ChatGPT
    │
    │ client_id 是一个网址
    ▼
🪪 CIMD 身份卡
    │
    │ Authorization Server 主动读取
    ▼
🏛️ Authorization Server

身份卡里有什么？

ChatGPT 的 CIMD 可以简化成：

{
  "client_id": "https://chatgpt.com/oauth/client.json",
  "client_name": "ChatGPT",
  "redirect_uris": [
    "https://chatgpt.com/connector_platform_oauth_redirect"
  ],
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://chatgpt.com/oauth/jwks.json"
}

翻译成人话就是：

字段	含义
client_id	我是谁
client_name	我的名字
redirect_uris	登录完成后可以回到哪里
token_endpoint_auth_method	我怎样证明自己的身份
jwks_uri	验证我签名的公钥在哪里

Authorization Server 怎么知道是哪个 Client？

看授权请求中的 client_id：

GET /authorize?
  client_id=https://chatgpt.com/oauth/client.json&
  redirect_uri=https://chatgpt.com/connector_platform_oauth_redirect&
  code_challenge=...

Authorization Server 会读取这个 URL 的 JSON，并检查：

• 文档中的 client_id 是否完全一致；
• redirect_uri 是否在允许列表中；
• Client 使用什么认证方式和公钥。

它会注册这个 Client 吗？

一般不需要。

传统方式是 Client 先调用注册接口，再由 Server 分配一个 client_id。

CIMD 中，URL 本身就是 client_id：

Client 提供 URL
      ↓
Server 读取 JSON
      ↓
直接进入 OAuth 流程

Server 可以缓存这份资料，但不必为每个新 Client 单独完成一次注册。

知道 URL 就能冒充吗？

不能。

任何人都可以复制 ChatGPT 的 CIMD URL，所以“拿出身份卡”还不够，还要证明自己拥有对应的私钥。

采用 private_key_jwt 时，这个证明会在拿授权码换 Token 时传过来：

POST /token

grant_type=authorization_code
&client_id=https://chatgpt.com/oauth/client.json
&code=...
&code_verifier=...
&client_assertion=eyJhbGciOiJSUzI1NiIs...

这里的 client_assertion 是用 Client 私钥签名的 JWT，不是私钥本身。

Client：JWT 内容 + 私钥 → 签名

Server：JWT 内容 + 签名 + 公钥 → 验证

Server 从 CIMD 的 jwks_uri 获取公钥，然后检查：

• 签名是否正确；
• iss、sub 是否对应这个 client_id；
• aud 是否是当前 Token Endpoint；
• JWT 是否过期；
• jti 是否已经使用过。

所以：

CIMD 告诉 Server“公钥在哪里”；私钥签名才证明“我真的是这个 Client”。

PKCE 和 private_key_jwt 有什么区别？

它们保护的东西不同：

机制	证明什么
PKCE	换 Token 的人参与了最初那次授权请求
private_key_jwt	换 Token 的人持有这个 Client 的私钥

两者可以同时使用，并不冲突。

三条安全提醒

1. 名称和 Logo 不能代表可信。 它们都是 Client 自己写的，还要检查域名、回调地址和签名。
2. CIMD 不能放私钥或 Client Secret。 它是任何人都能读取的公开文档。
3. 获取 CIMD 时要防 SSRF。 Authorization Server 不应访问内网、loopback 或其他危险地址。

最后记住三句话

网址是 client_id。

JSON 是公开的身份资料。

私钥签名才是身份证明。

CIMD 解决的是：一个陌生的 OAuth Client，怎样向 Authorization Server 介绍自己。

它简化了 Client 注册，但没有替代用户授权、PKCE、签名验证和 Token 安全。

参考资料

• OpenAI：Authentication patterns for plugin MCP servers
• IETF：OAuth Client ID Metadata Document
• Model Context Protocol：Authorization

CIMD 规范目前是 IETF Internet-Draft，实现时应以最新草案为准。