为何PKCE规范允许code_challenge_method=plain作为合法值？

PKCE（RFC 7636）保留plain方法主要有两个核心原因：

• 适配老旧/资源受限的客户端：规范制定时，考虑到部分早期系统（比如嵌入式设备、旧版移动应用）或者开发环境无法支持SHA-256哈希计算。plain方法允许这些客户端无需实现复杂的哈希逻辑，就能先接入PKCE的流程框架，获得基础的防护能力，后续再逐步迁移到更安全的S256方法。

• 提供最基础的授权码绑定防护：你提到的"授权码被盗则code_verifier也被盗"的情况存在误解——plain模式下，code_challenge等于code_verifier，但code_verifier是客户端本地生成并保存的，不会在授权请求中传输。攻击者即使拦截了授权码，若没有拿到客户端保存的code_verifier，依然无法向令牌服务器换取令牌。这比完全没有PKCE的授权码流程要安全：传统流程中，攻击者拿到授权码就能直接换令牌，而PKCE的plain模式至少要求攻击者同时获取授权码和客户端本地的code_verifier才能完成攻击。

当然，plain的安全性确实远不如S256——后者通过哈希把code_verifier转化为不可逆的code_challenge，彻底避免了code_verifier在网络传输中暴露的风险。像Auth0这类服务商弃用plain，是因为现在绝大多数客户端都能轻松实现SHA-256哈希，plain的防护力度已经跟不上现代安全需求了。

内容的提问来源于stack exchange，提问作者David Klempfner