为何无法在OAuth隐式授权流中使用客户端密钥或PKCE？

首先得明确：隐式流从设计之初就不是给能安全存储客户端密钥的Web应用用的，它的整个协议逻辑和安全模型都和你的需求不匹配，具体原因如下：

• 协议本身不支持这个操作
  按照OAuth 2.0的规范，隐式流的流程是直接在授权端点完成用户授权后，把令牌（通常是access_token）通过重定向返回给前端，根本没有专门的「令牌请求端点」来接收客户端密钥做验证。也就是说，协议里就没给你留传密钥的位置，硬加也不符合规范。

• 安全模型完全不兼容
  你觉得加了密钥就能和授权码流安全持平，但其实两者的安全逻辑天差地别：
  授权码流的核心安全是「授权码+客户端密钥」的双重验证——授权码只能用一次，且只有拿着合法密钥的服务器才能去换令牌，就算授权码被拦截，攻击者也拿不到令牌；而且令牌是在服务器之间传输的，不会暴露给前端。
  而隐式流就算你强行加密钥，最终令牌还是会直接返回给前端浏览器，依然存在被XSS攻击窃取的风险，同时隐式流本身没有授权码的一次性校验机制，安全性根本达不到授权码流的级别。

• 所谓的「效率」其实是伪命题
  你觉得隐式流少了授权码交换的步骤更高效，但现代授权码流配合PKCE使用时，流程复杂度和隐式流差不多，而且授权码流能拿到refresh_token，不用频繁让用户重新授权，长期来看反而更高效。另外，现在很多身份提供商已经逐步淘汰隐式流了，因为它的安全短板太明显。

如果你的Web应用有服务器端能安全存密钥，直接用**授权码流（带PKCE更稳妥）**就好，这才是符合你场景的最优解。

内容的提问来源于stack exchange，提问作者Alex BCH