SPA 应该在哪里保存 OAuth 2.0 访问令牌? [英] Where should a SPA keep a OAuth 2.0 access token?

问题描述

在授权代码授予流程中，一旦公共客户端(例如单页应用程序 (SPA))获得 OAuth 2.0 访问令牌，SPA 应将其保存在何处?

In a Authorization Code Grant flow, once a public client such as a Single Page Application (SPA) obtains a OAuth 2.0 access token, where should the SPA keep it?

• 将访问令牌存储在区域设置存储或会话存储中会导致跨站点脚本 (XSS) 攻击，因此应避免这种情况.
• 将访问令牌存储在非 httpOnly cookie 中也会导致 XSS 攻击，因此也应避免这种情况.
• 将访问令牌存储在 httpOnly cookie 中在技术上是不可能的，因为这是 httpOnly 的重点.

所以我看到的唯一安全的剩余选项是将它保存在内存中.它真的安全吗?这是唯一安全的方法吗?

So the only secure remaining option that I see is to keep it in memory. Is it actually secure? Is it the only secure way?

推荐答案

关键在于你愿意接受的风险.

It's all about the risk you want to accept.

如果您将其存储在 cookie 中，您可能会向 CSRF 开放您的应用程序.虽然通过将令牌存储在 httponly cookie 中将 XSS 交换为 CSRF 可能有意义，但使用非 httponly cookie 这样做没有多大意义，除了 CSRF 之外，也 容易受到 XSS 攻击.

If you store it in a cookie, you potentially open up your application to CSRF. While it may make sense to exchange XSS for CSRF by storing the token in a httponly cookie, it doesn't make much sense to do so with a non-httponly cookie that besides CSRF is also vulnerable to XSS.

在很多情况下将其存储在 localStorage 或 sessionStorage 中是可以的.选择它，您接受 XSS 访问令牌的风险.为了减轻这种风险，您可能需要实施缓解措施，例如使用合适的工具进行静态安全扫描、定期渗透测试等 - 安全不仅仅是代码，还包括围绕如何创建代码的过程.采取缓解措施后，您可以决定接受剩余风险.

Storing it in localStorage or sessionStorage is ok in many cases. With choosing that, you accept the risk of XSS having access to tokens. To mitigate this risk, you might want to implement mitigations, like for example static security scanning with a suitable tool, regular pentesting and so on - security is not just code, it's also processes around how you create that code. With mitigations in place, you can decide to accept the residual risk.

您还可以将令牌存储在内存中，例如我猜在 IIFE 中，从那里在 XSS 攻击中读取有点困难.将它存储在一个普通变量中没有帮助(来自 XSS 的 JavaScript 仍然可以访问)，而且我不完全确定最新的 JS 可以做什么来安全地使其无法从给定对象外部访问.以一种真正安全的方式可能是不可能的.

You can also store tokens in memory, like for example in IIFEs I guess, from where it's somewhat harder to read in an XSS attack. Storing it in a plain variable doesn't help (javascript from XSS would still have access), and I'm not entirely sure about what the latest JS can do to securely make it inaccessible from outside a given object. It's probably not possible in a way that is actually secure.

或者你可以走不同的路线.您可以在 localStorage 中存储非常短暂的访问令牌，接受 XSS 访问的风险.但是，您的 IdP 可以在 IdP 域的 httponly cookie 中发出刷新令牌.这样即使访问令牌被泄露，它也只在有限的时间内有效，然后攻击者将无法更新它.这在某些应用程序中可能有意义，而在其他应用程序中可能没有意义.

Or you can go down a different route. You can store very short-lived access tokens in localStorage, accepting the risk of XSS having access. However, your IdP can issue refresh tokens in httponly cookies for the IdP domain. This way even if an access token is compromised, it is only valid for a limited amount of time, and then the attacker will not be able to renew it. This may make sense in some applications, and probably not in others.

这篇关于SPA 应该在哪里保存 OAuth 2.0 访问令牌?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！