PKCE：保护公共客户端

如果没有 PKCE，移动应用容易受到授权码拦截攻击。当授权服务器将授权码重定向到应用注册的自定义 URI 方案（例如 myapp://callback）时，同一设备上任何注册了相同 URI 方案的恶意应用都可以拦截该重定向并窃取授权码。

攻击过程如下：恶意应用注册与合法应用相同的自定义 URI 方案。当授权服务器将代码重定向到 myapp://callback 时，OS 可能会将两个应用都显示为处理程序。如果用户选择了恶意应用，或者 OS 默认使用恶意应用，攻击者就会收到授权码，并且无需知道客户端密钥即可用它交换令牌。

PKCE（RFC 7636）会向授权码流程添加一个动态生成的秘密值。在启动流程之前，客户端会生成一个由密码学安全随机字符串组成的代码验证器，其长度为 43-128 个字符。该字符串对于每个授权请求都是唯一的，并且在令牌交换步骤之前不会被传输。

客户端根据验证器计算代码挑战值：code_challenge = BASE64URL(SHA256(code_verifier))。RFC 7636 要求使用 SHA256 方法（直接发送验证器的 "plain" 方法不推荐使用）。代码挑战值是验证器的单向转换结果，因此知道代码挑战值并不能推导出验证器。

授权请求会包含两个额外参数："code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256"。授权服务器会保存与已签发授权码相关联的代码挑战值。在此阶段不会向服务器传输任何可能被拦截的秘密值。

在令牌交换过程中（向令牌端点发送 POST），客户端会在授权码旁附带 "code_verifier=ORIGINAL_RANDOM_STRING"。授权服务器会计算 BASE64URL(SHA256(code_verifier))，并验证其是否与保存的 code_challenge 匹配。只有生成了该验证器的合法客户端才能通过此检查。

如果攻击者拦截了授权码，他只能获得代码和代码挑战值（该值是公开的）。要用代码交换令牌，他还必须提供代码验证器。由于验证器由合法客户端生成，并且直到安全进行令牌交换时才会被传输，攻击者无法计算或获取该验证器。

PKCE 还可防止授权码注入攻击：攻击者在重定向过程中用窃取的代码替换有效代码。窃取代码的挑战值与受害者客户端将提交的验证器不匹配，导致令牌交换失败。PKCE 可同时针对多种攻击向量提供纵深防御。

尽管 RFC 7636 最初被描述为面向公共客户端（没有客户端密钥的客户端）的解决方案，但 OAuth 安全最佳实践（BCP）和 OAuth 2.1 要求所有客户端都使用 PKCE，包括拥有客户端密钥的机密客户端。PKCE 提供独立于客户端身份验证的保护，因此对所有客户端都有益。

OAuth 2.1（draft-ietf-oauth-v2-1）将 OAuth 2.0 安全 BCP 中的安全最佳实践整合到一份文档中。它要求所有授权码流程都使用 PKCE，弃用隐式流程，并要求刷新令牌轮换。对于任何新的 OAuth 2.0 实现，PKCE 实际上都是必需的基线。

正确实现 PKCE 需要：使用密码学安全的随机生成器生成验证器（至少 32 个随机字节，然后进行 base64url 编码）；将验证器安全地存储在客户端中（而不是存放在 URL 或日志中）；使用 S256 方法（而不是 plain）；并确保在令牌交换后丢弃验证器。大多数现代 OAuth 库都会自动处理 PKCE。

在 PKCE 中，代码验证器与代码挑战值之间是什么关系？

PKCE（RFC 7636）通过将每个代码绑定到只有合法客户端知道的动态生成代码验证器，防止授权码被拦截。验证器经过哈希处理后生成代码挑战值（公开发送）。令牌交换需要原始验证器。PKCE 同时防止拦截攻击和注入攻击。OAuth 2.1 要求所有授权码流程都使用 PKCE。