authentication - OAuth 2.0 刷新 token 多个选项卡

Question

在使用 OAuth 2.0 JWT 刷新 token 实现时，我遇到了一个问题，即在 Web 浏览器客户端上实现可靠的刷新策略真的很困难。多个选项卡可能会导致请求出现竞争情况。

RFC 没有明确提到服务器端的刷新 token 仅对一个(第一个)请求有效，但我认为在使用刷新 token 时使它们无效是一个好主意。

堆栈溢出已经有多个“解决方案”，但似乎没有一个是直接的。

一种解决方案是向请求添加抖动并通过本地存储同步请求。

如果我理解正确，您会在请求启动时将变量放入本地存储，其他选项卡检查是否设置了此变量，然后不开始刷新？你知道这个的示例实现吗？也许在 React 中？

Answer 1

上面的答案并没有真正回答这个问题:

使用 OIDC 客户端库并没有解决这个问题，事实上据我所知它甚至不使用刷新 token 。

在内存或 session 存储中存储 token 并不能解决问题，但会产生更多，见下文。

在某些情况下，使用 AS 的 session cookie 是不可行的。通常这是一个跨域 cookie，不能在其他站点上可靠地使用。这个概念被称为“静默更新”，需要在 iframe 中使用跨域 cookie 来刷新 token (使用 AS session )。这个概念听起来不错，但是随着浏览器和用户阻止越来越多的跨域跟踪机制，这使用起来确实很危险:在大多数情况下，无法检测到被阻止的 cookie(这会导致几秒钟后突然注销，尤其是在使用 OIDC 时) session 管理机制. 刷新 token 时通过 AS 重定向也不是一种选择，因为在许多情况下， token 是 JWT 并且仅在几分钟内有效，并且每隔几分钟重定向离开应用程序来破坏体验也不是一种选择。

通过浏览器中的 PKCE 和授权代码流，可以使用和存储刷新 token ，但正如原始海报所说，刷新时必须小心(特别是当刷新 token 只能使用一次时，这是浏览器环境所需要的!)...