【OIDC】PKCE流程

OIDC PKCE (Proof Key for Code Exchange) 标准流程

1. 概述 (Overview)

PKCE(全称 Proof Key for Code Exchange，读作 “pixie”) 是对标准OAuth 2.0 Authorization Code Flow的安全扩展。它最初是为了解决移动应用（Native Apps）和单页应用（SPA）这类“公共客户端”（Public Clients）无法安全存储client_secret的问题而设计的，现在已成为所有类型客户端（包括 Web 应用）推荐的最佳实践。

PKCE 的核心思想是：客户端在请求授权码时，动态生成一个只有自己知道的“秘密”，并将其哈希值传给授权服务器；在随后换取令牌时，再出示原始的“秘密”供服务器校验。

2. 核心术语 (Key Terms)

在 PKCE 流程中，新增了三个关键参数：

1. Code Verifier (代码验证器)：
   • 客户端生成的一个随机、足够长的加密随机字符串。
2. Code Challenge (代码挑战)：
   • 对Code Verifier进行变换后的值。
   • 计算方法：Code Challenge = BASE64URL-ENCODE(SHA256(Code Verifier))。
3. Code Challenge Method (挑战方法)：
   • 通常设为S256（推荐使用 SHA-256 哈希算法）。

3. 标准交互流程 (Protocol Flow)

PKCE 流程主要分为三个阶段：准备、授权请求和令牌请求。

阶段 A：准备

客户端在发起登录前，本地生成一组密钥：

1. 生成随机字符串code_verifier。
2. 对code_verifier进行 SHA-256 哈希处理并进行 Base64Url 编码，得到code_challenge。

阶段 B：授权请求 (Authorization Request)

客户端将用户引导至授权服务器的/authorize端点，并在 URL 参数中额外携带 PKCE 信息：

• response_type=code
• client_id=...
• redirect_uri=...
• code_challenge={CHALLENGE_VALUE}
• code_challenge_method=S256

服务器行为：此时服务器会记录下code_challenge与该次授权请求的关联关系，然后完成用户登录并颁发授权码 (code)。

阶段 C：令牌请求 (Token Request)

客户端拿到code后，向服务器的/token端点发起 POST 请求。如果是公共客户端，此时不需要client_secret，但必须携带原始秘密：

• grant_type=authorization_code
• code={RECEIVED_CODE}
• client_id=...
• redirect_uri=...
• code_verifier={ORIGINAL_VERIFIER_SECRET}

服务器校验逻辑：

1. 服务器接收到code_verifier。
2. 根据之前记录的code_challenge_method(如 S256)，对这个code_verifier执行哈希计算。
3. 将计算结果与阶段 B 记录下来的code_challenge进行比对。
4. 只有匹配成功，服务器才会发放access_token和id_token。

4. 为什么 PKCE 更安全？

在没有 PKCE 的传统流程中，如果攻击者在中途拦截了授权码 (code)，由于公共客户端没有secret保护，攻击者可以直接用code换取access_token。

有了 PKCE 后：
即使攻击者截获了授权码code，因为他不知道客户端本地产生的原始code_verifier字符串，所以无法通过服务器在/token阶段的哈希校验。由于code_challenge是单向哈希，攻击者也无法反推出原始值。

5. 总结流程表