PKCE 增强授权代码流中保护 code_verifier 的最佳实践

Question

由于 PKCE 现在是隐式流程上推荐的授权方法，因此我正在寻找处理代码验证器的最佳实践以及如何完成此操作的建议。在高层 PKCE 授权流程中包括：

1. code_verifier在客户端生成
2. 生成code_challenge自 (1)
3. 点击/authorise哪个code_challenge重定向来选择 idp 并在回调中有一个code
4. 使用code(3) 中的 以及 来code_verifier交换访问令牌

问题是，在步骤 3 中，在应用程序重定向到授权服务器然后 idp 之前，必须将其存储code_verifier在某处。那是在什么地方？

似乎像okta-oidc-js存储code_verifier在 sessionStorage 中的库。这不会让您遭受 XSS 攻击吗？即，如果我在应用程序进入授权流程并重定向之前将其存储code_verifier在 sessionStorage 中，那么在回调中，什么会阻止某些 rouge 扩展从codeURL 和code_verifiersessionStorage 读取？其组合可用于交换访问令牌。

Answer 1

您所描述的是标准 SPA 的处理方式 - 它可能会被恶意代码滥用，但由于授权代码只能使用一次并且验证器不会长期存储，因此存在一些保护。

相关的 XSS 攻击是在隐藏的 iframe 上运行完整的 OAuth 授权重定向 + 代码交换 - 无论是否涉及后端或客户端机密，都无法防止这种情况。

如果您想严格控制安全性，新兴趋势更多的是前端方法的后端，其中后端是在https://api.mywebdomain.com上运行的“代理 API”

• OAuth授权的结果是API发出的同站cookie，防止上述iframe攻击

• 然后，SPA 可以使用身份验证 cookie 来获取访问令牌，或者通过代理 API 进行双跳 API 请求。

最近有一个关于 SPA 安全的精彩视频，进一步深入讨论了这些威胁。浏览器是一个很难实现安全性的地方，并且重定向会带来风险。

然而，仍然建议将 Web 和 API 问题分开 - 例如，上述代理 API 不应妨碍希望通过内容交付网络部署 SPA 的公司。

登录 舞动

在我看来，首选方法总结如下，以实现完全控制并且不会因最近的浏览器更改而出现问题：

• SPA 调用诸如https://api.mywebdomain.com/login/start之类的 URL ，该 URL 为包含状态和 code_verifier 的 .mywebdomain.com 写入仅 HTTP 加密的 cookie，并且还返回授权请求 URL

• 然后 SPA 自行进行重定向，并在需要时预先将页面位置/状态保存到会话存储中

• 然后，SPA 接收包含代码和状态的响应 URL，然后将它们 POST 到 URL，例如https://api.mywebdomain.com/login/end。之后SPA可以恢复其页面位置和状态，可用性良好。

• API 通过根据状态 cookie 中的状态验证状态，然后使用状态 cookie 中的 code_verifier 来完成登录。所有这一切的结果是编写一个不能在 iframe 上滥用的身份验证 cookie（包含刷新令牌）。