在OAuth2的PKCE机制中，为何响应中的code_challenge必须加密？

问题背景 #

RFC 7636第4.4节规定，将code_challenge嵌入授权码时必须采用加密形式（本次暂不讨论服务器存储方案），同时要求“服务器不得将code_challenge值以其他实体可提取的形式包含在客户端请求中”。针对这两条规则，存在以下疑问：

• 仅通过签名即可防止code_challenge被篡改，为何必须加密？
• 请求者本身知晓code_challenge，第三方也无法从中推导出code_verifier，为何禁止其他实体提取该值？

为何必须加密而非仅依赖签名？ #

签名确实能防止code_challenge被篡改，但加密还解决了签名无法覆盖的风险：

1. 阻断授权码泄露后的攻击路径：若授权码被攻击者窃取，未加密的code_challenge会被直接获取。虽然攻击者无法反向推导code_verifier，但可以利用已知的code_challenge构造恶意令牌请求——比如结合其他泄露的上下文信息，或利用客户端逻辑漏洞绕过验证。加密后，即使授权码泄露，攻击者也无法提取有效code_challenge，从根源上消除这类风险。
2. 维护授权码的不透明性：OAuth 2.0授权码的设计目标是不透明令牌，服务器以外的实体无需知晓其内部结构。将code_challenge加密嵌入，能保持授权码的不透明性，避免客户端或第三方依赖其内部格式，防止后续协议升级或服务器实现变更时出现兼容性问题。

为何禁止其他实体提取code_challenge？ #

这条规定的核心是最小化攻击面：

• 对客户端（请求者）而言，若能直接从授权码提取code_challenge，可能诱导不安全的逻辑设计——比如客户端放弃本地存储的原值，转而解析授权码中的值，这可能引入逻辑错误（如授权码被篡改后，客户端误判验证有效性）。
• 对第三方攻击者而言，获取code_challenge后可发起针对性字典攻击：虽然code_challenge是code_verifier的哈希值（通常为S256），但攻击者可预先构建常见code_verifier的哈希库，对获取到的code_challenge进行碰撞尝试。此外，在多客户端共享环境中，泄露的code_challenge可能被用来关联不同授权请求，追踪用户行为，违反隐私设计原则。

内容的提问来源于stack exchange，提问作者Martin Geisse