JsonWebToken：基于活动的过期与发布基于时间的过期答案

【问题标题】：JsonWebToken: activity-based expiration vs issuing time-based expirationJsonWebToken：基于活动的过期与发布基于时间的过期
【发布时间】：2015-02-09 02:31:34
【问题描述】：

我对基于令牌的授权相当陌生。我正在尝试找出自定义过期/令牌刷新方案中的缺陷。

我在 Express API 中有一个基本的 JWT 身份验证设置；我将 JWT 到期时间设置为 1 小时；但是，JWT 会检查相对于令牌发布时间的令牌过期时间。我希望在每次成功的 api 调用后重置过期时间。如果我的用户正在使用该应用程序超过一个小时，我不希望他们必须重新登录以刷新令牌（并且可能会丢失他们正在处理的任何数据。）

另一方面，如果令牌超过一个小时没有响应，我确实希望令牌过期。

我想出了以下方法：

在每个成功的 API 请求期间，发出一个新的 JWT 并将其发送到自定义响应头。我的客户端代码负责检查此 JWT 响应标头并将其值用作新的默认授权请求标头。因此，如果没有 API 用户请求超过 1 小时，令牌将过期并且不会被刷新。然后需要登录。此外，将存储令牌的原始发行日期（登录身份验证的时间戳），以便在 24 小时后强制执行令牌的“硬过期”。

这看起来相当简单且相当安全，但我在 JWT 研究中没有看到任何关于它的参考。有没有更好的方法来实现相同的目标？我是否错过了这种方法的主要安全漏洞？

更新： 在考虑了一段时间后，我意识到这样做的问题在于它打开了重放无法被令牌过期阻止的攻击的大门。所以绝对应该有一个“硬过期”检查：无论最近的用户活动如何，硬过期都会在发行日期后的某个时间使令牌失效。

【问题讨论】：

您是否根据旧令牌的有效性发行新令牌？除了您的客户端代码变得有点尴尬之外，我没有看到主要的安全问题。显然，发行新令牌不是免费的，因此在调用 API 时会付出性能损失。此外，您将无法将发布代码与 API 代码分开。 OAuth 2.0 使用刷新令牌在过期后更新已颁发的访问令牌。
@user18044 - 是的，我会根据旧令牌（以及其中包含的数据）的有效性颁发新令牌

标签： security authorization jwt express-jwt json-web-token

【解决方案1】：

您可以在这里查看我对这种情况的回答： implementing refresh-tokens with angular and express-jwt

我所做的是有一个时间窗口，服务器检查令牌过期和本地服务器时间是否在此窗口中，然后发送带有刷新令牌的响应头。

【讨论】：

【解决方案2】：

如果您同意并意识到无论如何您都需要一个硬到期时间，为什么不将（唯一的）访问令牌的到期时间设置为该时间并坚持使用普通的 OAuth 2.0？您现在正在做的事情的渐近线是在第一次使用访问令牌（在 API 响应中）后发布您自己的 API 特定令牌/cookie，并基于此强制执行后续 API 访问。这是一种有效的方法，但在您自己的 API 中复制了许多现有的 OAuth 2.0 授权服务器功能。我认为没有充分的理由去那里。

【讨论】：

这种方法可以让我在很短的一段时间后使令牌失效，但前提是用户变为非活动状态。例如，如果用户在公用计算机上并且说用户没有注销就离开了，您可以让令牌在最后一次 API 调用后 30 分钟过期。我不想将硬过期设置得这么短，因为无论用户的活动如何，用户都必须每 30 分钟登录一次。烦人，并可能导致数据丢失（比如他们填写并提交了很长的表格）。
您将令牌到期与用户登录到期混为一谈；他们不一样
好的，我可以不做这方面的专家。也许您可以解释我如何通过分离这些关注点来实现我所说的目标？或者你可以给我指出一个资源？
授权服务器上存在登录会话；客户端使用的令牌的到期时间相对独立；每当客户端的令牌过期时，它都会向授权服务器咨询新的令牌；如果用户可以成功进行身份验证或者登录会话仍然存在（这就是您要查找的内容），则会发出一个新令牌
好的，谢谢，我相信我理解这个模式。我想我认为会话的要求是不利的 - 这就是让 JWT 对我首先有吸引力的原因。