注意：我完全承认图片中可能缺少一些东西，这是我发帖的部分原因。我想获得比我在 authN/Z 相关实现方面更有经验的人的意见。

这就是我被困在整个“客户端应用程序上没有刷新令牌”的地方：

我的假设是，如果没有刷新令牌，出于用户体验的原因，我们也不能总是拥有一个非常短暂的访问令牌，即如果我们有一个访问令牌每 15 分钟过期一次，并且没有机会刷新我们' d 必须每 15 分钟重新登录一次。

我的问题：通过延长访问令牌的生命周期，我们为潜在的 MIDM 攻击者提供了一种更加危险的武器，即一种令牌，它可以访问可能持续数天甚至永远的资源（正如我在远项目太多）。

对我来说，解决这种情况的最简单方法是刷新令牌，甚至是位于前端的令牌，因为在我看来，它仍然胜过持久的 ACCESS 令牌。

此刷新令牌可能是：

• 还有一个过期的 JWT，但可能会在一周左右过期
• 用于刷新访问令牌然后被新的刷新令牌替换的“仅使用一次”令牌

在我看来，这种方法与长期访问令牌相比解决了一些问题：

• 通过这种方法，我可以保留一个短暂的访问令牌，所以如果它落入坏人手中，它就不能长期使用

• 如果您认为刷新令牌更糟，我不同意，因为有两件事使它变得更好：

  1. 一旦主用户再次刷新他的令牌，以前的刷新令牌将不再可用
  2. 如果我们假设有人在我们浏览时窃取了我们的刷新令牌，在几分钟内，我们的浏览器将尝试使用该刷新令牌，失败（因为其他人使用了它，因此它不再可用）并提示我们登录，这将再次使恶意实体获得的其他一系列刷新令牌完全失效
  3. 即使 1 和 2 在所有情况下都不是真的（我认为允许多个会话/刷新令牌，所以不是单个堆栈或刷新令牌而是多个）我仍然打赌你最好通过任何程序使刷新令牌无效你想要的比你使访问令牌无效。JWT 访问令牌本身是有效的，使用它的全部目的是您可以通过验证它来信任它，而无需执行其他昂贵的操作，例如检查身份验证服务器是否被列入黑名单。这本质上意味着必须为每一个使用每个访问令牌完成的请求检查这种事情=不是非常可扩展，特别是如果你将它与每 15 分钟必须为刷新令牌做一次这种事情进行比较（你可以保留刷新令牌黑名单）。

那么，综上所述，客户端“使用一次”刷新令牌也是 JWT 并且过期不合理吗？上周我们正在避免获得访问令牌，这怎么可能？