直接回答：授权码流程的假设是 client_secret 能保密，但公共客户端（移动 App、SPA）没有安全的 secret 存放处，授权码在重定向回客户端的路上可能被恶意应用（抢注相同 URL scheme）或浏览器扩展截获。PKCE（RFC 7636）让客户端每次授权时生成随机 code_verifier，授权请求只带其哈希（code_challenge），换令牌时再出示原文。授权服务器验哈希一致才发令牌——截获授权码的攻击者没有 verifier，换不到令牌。

展开解析：细节决定安全性：code_challenge_method 必须用 S256（SHA-256），plain 模式形同虚设；state 参数仍要用于防 CSRF，PKCE 不替代它；授权码本身应一次性、短时效、绑定 redirect_uri。如今 PKCE 已成为所有客户端（包括有 secret 的机密客户端）的推荐基线——它同时防住了授权码注入类攻击。相关演进：隐式流程（implicit）因令牌直接暴露在 URL 已被 OAuth 2.1 废弃，一律用授权码+PKCE；设备授权（device flow）解决无浏览器设备；DPoP/mTLS 发送者约束令牌则更进一步，把令牌绑定到持有者密钥，偷走令牌也用不了。

追问方向：state 参数防 CSRF 的机制？OAuth 2.1 做了哪些收编？redirect_uri 开放重定向如何导致授权码泄漏？

（约 430 字）