oauth-2.0 - 为什么刷新 token 被认为对于 SPA 来说是不安全的？

Question

我正在阅读 Auth0 网站上有关 Refresh Tokens and SPA 的文档，他们指出 SPA's should not use Refresh Tokens因为它们无法安全地存储在浏览器中，而是使用静默身份验证来检索新的访问 token 。

A Single Page Application (normally implementing Implicit Grant) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.

我很困惑。根据我的理解，检索新访问 token 的唯一方法是向 Auth 服务器提交新请求，以及某种形式的 Auth0 session cookie，以对登录的用户进行身份验证。收到 session cookie 后，Auth0然后服务器将能够颁发新的访问 token 。

但这与在浏览器或本地存储中拥有刷新 token 有何不同？是什么让 session Cookie 比刷新 token 更安全？为什么在 SPA 中使用刷新 token 是一件坏事？

Answer 1

关于 cookie 和刷新 token 以及 OAuth2 存在很多误解。

首先，只有 secret 客户端才能使用刷新 token 的说法并不正确。 OAuth2 协议(protocol)规定 secret 客户端必须进行身份验证，但并不要求 secret 客户端。因此，客户端身份验证在刷新操作中是可选的。请参阅RFC 6749, Section 6, Refreshing An Access Token .

其次，您必须了解替代方案是什么:

1. 强制用户每 5 分钟输入一次用户名和密码(每当访问 token 过期时)
2. 长期访问 token
3. 通过 HTTP Cookie 进行身份验证

世界上每个不使用刷新 token 的人都使用选项#3。通过 cookie 进行身份验证在功能和安全方面 100% 等同于存储刷新 token 。当然，对于 token 和 cookie，它们的保存位置有多种选择:

a.仅 HTTP， b.安全(需要 TLS/SSL)和 C。 session (内存中)与持久性(本地、域存储)

“仅 HTTP”选项仅适用于 cookie，因此可能代表使用 cookie 相对于 token 的唯一优势。 IE。 token 是通过 Javascript 处理的，因此无法让它们远离脚本。也就是说， token 仅可用于存储该 token 的页面域中的 Javascript(或 CORS 策略允许的情况)。所以这个问题可能被夸大了。

当然，必须注意始终使用 TLS/SSL 传输身份验证 cookie 或 token 。老实说，由于我们知道大多数违规行为都发生在私有(private)企业网络内，因此端到端 TLS 不再是一项基本要求。

最后，cookie 或 token 是否持久，即存储在关闭浏览器甚至重新启动设备后仍然存在的位置，取决于您在可用性和安全性之间进行的权衡 - < em>用于您的应用程序。

对于需要更高级别安全性的应用程序，只需将所有内容保留在内存中(即 session cookie、Javascript 变量中的 token )。但对于不需要太多安全性并且确实希望 session 生命周期为几天或几周的应用程序，那么您需要存储它们。无论哪种方式，该存储只能由原始域中的页面和脚本访问，因此 cookie 和 token 在功能上是等效的。