oauth-2.0 - 使用 JWT token 身份验证时是否真的需要刷新 token ？

Question

我正在引用另一篇 SO 文章，该文章讨论了将刷新 token 与 JWT 一起使用。

JWT (JSON Web Token) automatic prolongation of expiration

我有一个具有非常通用架构的应用程序，其中我的客户端(Web 和移动)与 REST API 通信，然后与服务层和数据层通信。



我了解 JWT token 身份验证，但我对如何使用刷新 token 感到有些困惑。

我希望我的 JWT 身份验证具有以下属性:

JWT token 的有效期为 2 小时。

客户端每小时刷新一次 token 。

如果用户 token 未刷新(用户处于非事件状态且应用程序未打开)并过期，则他们将需要在想要恢复时登录。

我看到很多人声称使用刷新 token 的概念使其成为更好的体验，但是，我没有看到这样做的好处。管理它似乎增加了复杂性。

我的问题如下:

如果我要使用刷新 token ，那么为该 token 的良好实践设置一个长期到期是否仍然有益？

如果我要使用刷新 token ，该 token 是否会与 userId 和/或 JWT token 一起保存？

当我每 1 小时更新一次 token 时，这是如何工作的？我要创建一个接收我的 JWT token 或刷新 token 的端点吗？这会更新我的原始 JWT token 的到期日期，还是创建一个新 token ？

鉴于这些详细信息，是否需要刷新 token ？似乎如果用户只是使用 JWT token 来获取新 token (根据上面的链接)，则刷新 token 已过时。

Answer 1

让我稍后再回答您的问题，并从实际讨论刷新 token 的整个目的开始。

所以情况是:

用户打开应用程序并提供他的登录凭据。现在，该应用很可能正在与 REST 后端服务进行交互。 REST 是无状态的，无法授权访问 API。因此，到目前为止，在讨论中，没有办法检查授权用户是否正在访问 API 或只是一些随机请求正在通过。

现在为了能够解决这个问题，我们需要一种方法来知道请求来自授权用户。所以，我们所做的是引入一种叫做访问 token 的东西。所以现在一旦用户成功通过身份验证，他就会获得一个访问 token 。这个 token 应该是一个长且高度随机的 token (以确保它不能被猜到)。这就是 JWT 出现的地方。现在您可能/可能不想在 JWT token 中存储任何特定于用户的详细信息。理想情况下，您只想在 JWT 中存储非常简单、非常不敏感的细节。 JWT 哈希操作以检索其他用户的详细信息(IDOR 等)由 JWT(正在使用的库)本身负责。

所以，现在，我们的授权访问问题已经解决。

现在我们谈论一个攻击场景。假设使用上述所有用户 Alice，使用该应用程序，拥有授权访问 token ，现在她的应用程序可以向所有 API 发出请求并根据她的授权检索数据。

假设 不知为何 Alice 丢失了访问 token ，或者换句话说，对手 Bob 可以访问 Alice 的访问 token 。现在，尽管未经授权，Bob 可以向 Alice 授权的所有 API 发出请求。

我们不想要的东西。

现在这个问题的解决方案是:

要么检测到发生了这种事情。

减少攻击窗口本身。

仅使用访问 token 很难实现上述条件 1，因为无论是 Alice 还是 Bob，都使用相同的授权 token ，因此无法区分来自两个用户的请求。

所以我们尝试实现上面的 2，因此我们为访问 token 的有效性添加了一个过期时间，假设访问 token 在“t”(短暂)时间内有效。

它有什么帮助？好吧，即使 Bob 拥有访问 token ，他也只能在有效时使用它。一旦它到期，他将不得不再次取回它。现在，当然，你可以说他可以像第一次得到它一样得到它。但话又说回来，没有什么能像 100% 安全!

上述方法仍然存在问题，并且在某些情况下是 Not Acceptable 。当访问 token 过期时，它将要求用户输入他的登录凭据并再次获取授权访问 token ，至少在移动应用程序的情况下，这是一种糟糕的( Not Acceptable )用户体验。

解决方案:这就是刷新 token 的用武之地。它也是一个随机的不可预测的 token ，首先也与访问 token 一起发布给应用程序。这个刷新 token 是一个非常长的特殊 token ，它确保一旦访问 token 到期，它就会向服务器请求一个新的访问 token ，从而消除用户重新输入其登录凭据来检索的需要一个新的授权访问 token ，一旦现有 token 过期。

现在您可能会问，Bob 也可以访问刷新 token ，类似于他破坏访问 token 的方式。是的。他可以。但是，现在很容易识别这样的事件，这在单独使用访问 token 的情况下是不可能的，并采取必要的措施来减少造成的损害。

如何？

对于每个经过身份验证的用户(通常在移动应用程序的情况下)，会向应用程序发出一对一映射的刷新 token 和访问 token 对。因此，在任何给定时间点，对于单个经过身份验证的用户，将只有一个访问 token 对应于刷新 token 。现在假设如果 Bob 破坏了刷新 token ，他将使用它来生成访问 token (因为访问 token 是唯一有权通过 API 访问资源的东西)。一旦 Bob(攻击者)请求使用新生成的访问 token ，因为 Alice(真正的用户)的访问 token 仍然有效，服务器就会将此视为异常，因为对于单个刷新 token ，在一个时间。识别异常后，服务器将销毁有问题的刷新 token ，同时它的关联访问 token 也将失效。从而防止对任何需要资源的授权的任何进一步访问，无论是真实的还是恶意的。
用户 Alice 将被要求再次使用她的凭据进行身份验证并获取一对有效的刷新和访问 token 。

当然，您仍然可以争辩说 Bob 可以再次访问刷新和访问 token 并重复上面的整个故事，这可能会导致对真正的真正客户 Alice 的 DoS，但再一次，没有什么比 100% 安全.

同样作为一个好习惯，刷新 token 应该有一个过期时间，虽然很长。