为什么刷新令牌被认为对SPA不安全？

Question

我正在阅读 Auth0 站点上有关刷新令牌和 SPA 的文档，他们指出 SPA 不应使用刷新令牌，因为它们无法安全地存储在浏览器中，而是使用静默身份验证来检索新的访问令牌。

单页应用程序（通常实施

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

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

Answer 1

SPA中不使用刷新令牌，因为为了使用它——并从/Tok获取新的访问令牌，SPA需要有一个客户端机密，该机密不能安全地存储在浏览器中。但是由于原生应用程序的OAuth 2.0 RFC建议不需要/Tokendpoint的客户端机密（对于公共客户端），刷新令牌甚至可以在SPA中使用。

要获得刷新令牌，您需要使用身份验证代码授权，该授权将代码传递到重定向URL中，该重定向URL将到达托管SPA的服务器（这可能是额外的攻击点）。隐式授权仅将令牌传递到浏览器（重定向URL的哈希部分不会到达服务器）。

使用刷新令牌和 SSO 会话 cookie 之间的区别 - cookie 可能更安全，因为它可以标记为 HttpOnly，这使得使用 JavaScript 代码的攻击无法访问它。

更新

使用 PKCE 扩展，授权代码流（带有刷新令牌）成为推荐流，即使对于基于浏览器的应用程序也是如此。有关详细信息，请参阅最新版本的 OAuth 2.0 基于浏览器的应用程序 RFC。

Answer 2

这不再是真的了(2021年4月)，Auth0网站现在声明了一件不同的事情:

Auth0 建议使用刷新令牌轮换，这提供了一种在 SPA 中使用刷新令牌的安全方法，同时为最终用户提供对资源的无缝访问，而不会因 ITP 等浏览器隐私技术而导致的用户体验中断。

Auth0以前的指导方针是在spa中结合静默认证使用带有代码交换证明密钥(PKCE)的授权代码流。这是一个比隐式流更安全的解决方案，但不如具有用于代码交换的证明密钥(PKCE)和刷新令牌轮换的授权代码流安全。

请注意在刷新令牌中启用轮换的重要性。

Answer 3

关于cookies和刷新令牌以及OAuth2都有很多误解。

首先，只有机密客户端才能使用刷新令牌是不正确的。OAuth2协议说机密客户端必须进行身份验证，但不需要机密客户端。因此，客户端身份验证在刷新操作中是可选的。请参见RFC 6749，第6节，刷新访问令牌。

其次，你必须了解备选方案是什么：

1. 强制用户每5分钟输入一次他或她的用户名和密码（每当访问令牌到期时）
2. 长期访问令牌
3. 通过HTTP Cookies进行身份验证

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

a、 仅HTTP，b.安全（需要TLS/SSL）和c.会话（内存中）vs.持久（本地、域存储）

“仅HTTP”选项仅适用于cookie，因此，这可能是使用cookie优于令牌的唯一优势。一、 e.代币是通过Javascript处理的，因此没有办法让它们远离脚本。也就是说，这些令牌只能从存储它的页面的域（或CORS策略允许的域）提供给Javascript。所以这个问题可能被夸大了。

当然，必须注意始终使用TLS/SSL来传输身份验证cookies或令牌。老实说，因为我们知道大多数违规都发生在私有企业网络内部，所以端到端TLS不再是一项基本要求。

最后，cookie 或令牌是否持久化，即存储在关闭浏览器甚至重新启动设备后幸存下来的地方，取决于您在可用性和安全性之间做出的权衡 - 为您的应用程序。

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