In a 授权码授予流程中，一旦单页应用程序 (SPA) 等公共客户端获得 OAuth 2.0 访问令牌，SPA 应该将其保存在哪里？
- 将访问令牌存储在区域设置存储或会话存储中会导致跨站点脚本 (XSS) 攻击，因此应避免这种情况。
- 将访问令牌存储在非 httpOnly cookie 中也会遭受 XSS 攻击，因此也应该避免这种情况。
- 将访问令牌存储在 httpOnly cookie 中在技术上是不可能的，因为这是 httpOnly 的重点。
因此，我看到的唯一安全的剩余选项是将其保留在内存中。它真的安全吗？这是唯一安全的方法吗？
这完全取决于您愿意接受的风险。
如果将其存储在 cookie 中，则可能会向 CSRF 开放您的应用程序。虽然通过将令牌存储在 httponly cookie 中来用 XSS 交换 CSRF 可能是有意义的，但使用非 httponly cookie 来这样做没有多大意义，除了 CSRF 之外also容易受到 XSS 攻击。
在很多情况下，将其存储在 localStorage 或 sessionStorage 中就可以了。选择该选项后，您就接受了 XSS 访问令牌的风险。为了减轻这种风险，您可能需要实施缓解措施，例如使用合适的工具进行静态安全扫描、定期渗透测试等 - 安全不仅仅是代码，它还包括围绕如何创建代码的过程。缓解措施到位后，您可以决定接受残余风险。
您还可以将令牌存储在内存中，例如我猜在 IIFE 中，从那里在 XSS 攻击中读取起来有些困难。将其存储在普通变量中并没有帮助（来自 XSS 的 javascript 仍然可以访问），而且我不完全确定最新的 JS 可以做什么来安全地使其无法从给定对象外部访问。以真正安全的方式可能是不可能的。
或者你可以走另一条路。您可以在 localStorage 中存储非常短暂的访问令牌，并接受 XSS 访问的风险。但是，您的 IdP 可以在 IdP 域的 httponly cookie 中发出刷新令牌。这样，即使访问令牌被泄露，它也仅在有限的时间内有效，然后攻击者将无法更新它。这在某些应用程序中可能有意义，但在其他应用程序中可能没有意义。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
