按理说，

：一个字符串背后的身份程序

在 OAuth 的整个环境里client_id 是出现频率最高却最容易被忽视的参数之一。它几乎出现在每一个授权请求的 URL 里开发者往往只是将其视为“配置项”，从 IdP 控制台粘贴进代码就完事了。

使用者痛点：很多团队在生产环境中意外泄露 client_id导致恶意应用成合法客户端，进而发起钓鱼或授权码替换攻击。

深入 RFC 规范后会发现：client_id 不仅仅是一个标识符，它是整个 OAuth 授权程序中“客户端身份”这一概念的具体承载形式。 怎么说呢， 它的设计决策、使用约束和安全含义。 折射出 OAuth 协议委托授权模型的主要架构思想。

从规范基础来看。RFC 的定义与本质

官方定义

RFC 6749 §2.2 给出了 client_id 的权威定义：

三个关键词值得单独拆解：

再看主要约束。不是秘密

RFC 明确指出：

User Pain Point： 很多团队把 client_id 当作密码来保管，一旦泄露就会错误地认为程序已经失陷。它本质上是息，可出现在：

• 浏览器地址栏
• 前端 JavaScript 源码
• 移动应用的反编译代码
• HTTP 服务器日志等可审计渠道

true secret 是 client_secret 或 PKCE 的 code_verifier。

RFC 刻意回避了对字符串长度的规定：

不同 IdP 的实现差异示例：

• 再看Google，格式
• GitHub这方面。十六进制随机串
• Azure AD：UUID v4
• Keycloak：可配置任意字符串

**工程建议**：数据库字段不要使用固定长度 CHAR，而应采用 VARCHAR 或更大，以兼容所有实现。

制：动态客户端注册

从哪里来

RFC 7591 定义了动态客户端注册协议，规定了 client_id 的生命周期起点：

POST /register HTTP/1.1
至于Host，server.example.com
Content-Type: application/json
{
"redirect_uris":,"client_name": "My Example Application","grant_types":。"response_types":
}

成功注册后返回：

{
"client_id": "s6BhdRkqt3","client_secret": "cf136dc3c1fc93f31185e5885805d","client_id_issued_at": 1609459200,"client_secret_expires_at": 0,"redirect_uris":
}

RFC 明确要求 client_id 必须由服务器生成，**禁止客户端自行指定**。

为何禁止客户端自选 ID

安全设计背后的背后原因：

• 攻击者可在恶意 AS 上注册与合法 AS 相同的 client_id
• 诱导使用者访问恶意 AS 授权端点 → 钓鱼成功
• 利用熟悉的 ID 提高社会工程学可信度

同一 client_id 对多实例的例外

RFC 附录 A 允许在特定场景下向多个实例颁发相同 ID。但必须满足严格限制，例如移动端多个安装实例共享同一 ID 时需要配合 PKCE 保证每次流程独立。

client_id 在各授权流程中的角色

Authorization Code Grant

GET /authorize?responsetype=code&
clientid=s6BhdRkqt3&
redirect_uri=https://app.example.com/callback&
scope=read&
state=xyz
从Host来看。server.example.com

此处 **client_id** 为必需参数，授权服务器据此：


检索已注册的 redirect_uri 白名单；若不匹配则直接拒绝，老实说，

在授权页面展示应用名称、logo 等信息。让资源所有者确认 “是谁在请求”。怎么说呢，

校验请求的 scope 是否在该 client 授权范围内。


http
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

granttype=authorizationcode& code=SplxlOBeZQQYbYS6WxSbIA& redirecturi=https://app.example.com/callback& clientid=s6BhdRkqt3 ← 公共客户端必需 RFC 强调：