security - 刷新 token 轮换 - 真的够了吗？

Question

在使用 OIDC 服务器进行身份验证的单页应用程序 (JavaScript) 的上下文中，保持 session 事件(在过期后获得更多 token )的标准和推荐方法是使用 HttpOnly Cookie 并在 iframe 中执行静默更新.太好了，不涉及刷新 token ，因为浏览器无法保密。
现在似乎浏览器将阻止跨域 Cookie(Safari 和 Brave 已经这样做了，Chrome 似乎是下一个)，所以如果服务器位于不同的域上，那么 future 的唯一方法似乎是使用 刷新 token 与 刷新 token 轮换 (可能还有 重用检测 )，这似乎可以缓解这些问题。但真的吗？
场景1) 刷新 token (RT1) 被盗，用户请求一个新的 token 并由于轮换而取回一个新的刷新 token (RT2)。 RT1 现在无效，攻击者无法使用。伟大的。
场景 2) 刷新 token (RT1)被盗，攻击者执行请求获取新 token (RT2)，用户使用旧 token (RT1)，现在一切都被丢弃，用户必须再次登录(重用检测)和攻击者的 token 也是无效的。伟大的。好吧，我在这里看到了一个问题(用户必须再次登录，但不知道为什么)，但至少问题解决了。
场景 3) 这是我在任何地方都没有看到的场景。假设攻击者在不使用它们的情况下窃取了每个后续的 RT，因此它继续窃取 RT1。用户刷新，攻击者也窃取了 RT2。一切正常，因为攻击者没有使用 token ，但也许他将所有 token 发送到其他地方进行存储。最后，用户关闭窗口，攻击者提取了 RT1 和 RT2。此时，攻击者可以使用最新的 RT (RT2) 来冒充用户，直到用户返回该应用程序。假设他离开一周，攻击者拥有一周的新访问 token (他可以不断刷新 token )。直到最后，没有人注意到任何事情。使用 Cookie，攻击者只能在浏览器 session 期间进行操作，现在它有更多的时间来做这件事。
那么……带有重用检测的 RTR 真的足够安全吗？主要论点是“它总是一个风险/ yield 选择”，我明白，但怎么会是 2020 年，我们仍然在浏览器方面遇到问题？你看到我遗漏的第三个场景有什么问题吗？老实说， session cookie 一直是最好的选择，事实上浏览器会阻止我们在这种常见情况下使用它们，这让我发疯:)
谢谢。
附注。我将在此处复制我找到的有关此问题的一些资源:

https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications.html

“RTR 不是一个包罗万象的安全措施。如果攻击者设法在应用程序关闭之前获得最后一个刷新 token ，他们可能能够不断轮换被盗的刷新 token 。为了避免长期滥用被盗的刷新 token ，安全 token 服务可以将该刷新 token 的生命周期与用户与安全 token 服务的 session 的生命周期相关联。这样做会在 session 到期时使刷新 token 无效。”
这是我在场景 3 中提出的观点，但他建议的解决方案是将 RT 链接到用户的 session 。所以，我们又在使用 Session Cookies 了，不是吗？如果我们不能使用它们怎么办？当我们不能使用跨域 cookie 时，这种情况下的 RT 应该是一种替代方法。

https://leastprivilege.com/2020/03/31/spas-are-dead/

这个人似乎同意我的观点，即即使使用 RTR，RT 也不够安全，SPA 需要连接到同一域上的后端才能像以前一样工作。

Answer 1

这是一个有趣的领域，它通常是可用性、安全性、性能和成本之间的权衡。该行业的当前状态非常不令人满意，但我希望其中的一些内容可以帮助您了解主要问题。
在浏览器中刷新 token
在使用这个解决方案之前，我会确保授权服务器正确支持 OAuth 2.1 RTP recommendations - 没有多少授权服务器这样做。
然后我会确保我只在应用程序的内存中存储刷新 token ，因为不建议将 token 存储在本地存储中。这意味着:

多标签浏览或重新加载页面将需要通过您提到的基于 iframe 的旧解决方案刷新 token

这不会在 Safari 中静默运行，因此会有一个浏览器重定向，可用性利益相关者可能会提示

安全方面
当然，您的 SPA 安全不仅仅是 token 机制。您需要确保安全利益相关者接受该解决方案，并且您需要考虑威胁，例如攻击者可以使用 token /cookie 做什么。
前端模式的后端
这样做的一个大问题是，您通常需要一个后端来发布相同域的 HTTP 加密 cookie，用 C#、Node、Java 等编码。
这对于 SPA 架构来说可能非常具有侵入性:

通过内容交付网络将 Web 静态内容推送到许多全局位置是不可能的或更困难的

您可能需要对来自 SPA 的每个 API 调用进行双跳，这会增加复杂性，尤其是在缓存和 API 错误响应等领域

使用 auth cookie 并没有“解决”安全问题，许多浏览器威胁仍然需要处理

我的资源
您选择的解决方案可能取决于您要达到的最终状态。我现在更喜欢的全面架构选项是将访问 token 存储在浏览器内存中并使用 同域 HTTP Only 加密 Cookie 用于 token 更新。
我的以下帖子可能会帮助您更多地思考您想要从自己的解决方案中得到什么:

SPA End State

Browser Threat Model