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

Question

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

1. 在客户端生成

   code_verifier

2. 从 (1)

    生成 

   code_challenge
3. 点击

   /authorise

   和

   code_challenge

   会重定向到选择 idp，并且在回调中会有一个

   code

4. 使用 (3) 中的

   code

   以及

   code_verifier

   来交换访问令牌

问题是，在步骤 3 中，在应用程序重定向到授权服务器然后是 idp 之前，必须将

code_verifier

存储在某处。 那是哪里？

似乎像

okta-oidc-js

这样的库将

code_verifier

存储在sessionStorage中。这不会让您遭受 XSS 攻击吗？也就是说，如果我在应用程序进入授权流程并重定向之前将

code_verifier

存储在 sessionStorage 中，那么在回调中，什么会阻止某些 rouge 扩展从 URL 中读取

code

和从 sessionStorage 中读取

code_verifier

？其组合可用于交换访问令牌。

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 到诸如 https://api.mywebdomain.com/login/end 之类的 URL。之后SPA可以恢复其页面位置和状态，因此可用性很好。

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

Answer 2

我同意加里的方法，但有一点改变。 带有代码和状态的响应 url 不需要被 SPA 拦截并转换为对 BFF（前端的后端）的另一个 POST 调用。 如果在包含状态和代码验证器的流程开始时在浏览器上设置了安全 cookie，则响应 url 可以直接登陆 BFF，然后 BFF 将具有可用于执行代码交换的所有参数（状态和代码作为 url 参数，来自 cookie 的 code_verifier）

Answer 3

您好，我正在将 OKTA SPA 与 cognito 一起使用，但是当我使用托管 ui 时，在 url 中附加代码质询和代码质询方法之后，cognito 似乎没有将代码质询传递给 okta，然后只有它重定向到 OKTA 登录页面。之后我也获得了代码，但由于代码验证器不存在，因此无法获取令牌，但我如何在托管用户界面中提供该令牌？