试图找到一个带有刷新令牌的“万无一失”oauth 架构示例

Posted 2023-03-10

【中文标题】试图找到一个带有刷新令牌的“万无一失”oauth 架构示例

【英文标题】：Trying to find an example of "foolproof" oauth architecture with refresh tokens

【发布时间】：2018-03-17 21:20:39

【问题描述】：

我正在为我的 Angular 应用程序设置带有刷新令牌的 oauth，并且我有一个要求列表：

定期刷新令牌（例如，当剩余 5% 的时间时） 处理连接中断（再次连接时刷新） 处理浏览器中的多个选项卡（所有选项卡都尝试同时刷新同一个令牌、在另一个选项卡中退出等） 令牌无效/刷新时暂停/重试 HTTP 请求

目前我正在尝试自己构建整个刷新逻辑，但我不断遇到使过程复杂化的极端情况。例如多个选项卡。一个选项卡刷新令牌并获得一个新的。在另一个选项卡开始执行此操作之前，它会尝试刷新旧令牌（使用现在无效的刷新令牌）并且刷新失败。

我觉得肯定有很多其他人和我有相同的要求，并且必须有示例/库/开源项目与此完全一致？有谁知道任何可以帮助我的资源？

【问题讨论】：

我建议重述这个问题，不要专注于寻求资源，因为这类问题是off-topic。 ***.com/help/mcve 与当前的 oauth 尝试（github.com/angular/in-memory-web-api 可用于无服务器示例）也可以帮助保持主题。由于可能的好答案是有限的，所以这个问题有它的机会。

【参考方案1】：

我们正是这样做的，但我怀疑是否有任何库可用于整个设置，因为这涉及前端和后端，并且您可能会为每种甚至可能不同的编程语言使用不同的框架。

简而言之，我们应用的解决方案是：

登录后，客户端获得访问令牌和刷新令牌 刷新令牌作为仅 HTTPS cookie 呈现给客户端 访问令牌由客户端存储在本地存储中 同步过程可确保访问令牌在选项卡中的多个客户端之间同步 Access Token 过期后，401 请求被拦截，并使用 Refresh Token 请求新的 Access Token 失败的401请求自动重试() 当其中一个选项卡获得新的访问令牌时，其他客户端通过同步过程获取并使用新的访问令牌

拼图有很多部分，但一旦您清楚自己在做什么以及希望它如何工作，设置起来并不难。与所有事情一样，根据您自己的特定用例和安全要求，当然还有很大的修改或改进空间。