JsonWebToken：基于活动的到期与发布基于时间的到期

Question

我对基于令牌的授权相当新。我试图找到自定义过期/令牌刷新方案中的缺陷。

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

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

我提出了以下方法：

  

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

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

更新 在考虑了一段时间之后，我意识到这个问题就是它打开了重放攻击的大门，这些攻击无法通过令牌过期来阻止。因此，绝对应该进行“硬到期”检查：无论最近的用户活动如何，硬到期都会在发布日期后的某个时间使令牌无效。

Answer 1

在这里，您可以查看我的答案： implementing refresh-tokens with angular and express-jwt

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

Answer 2

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