如您所知，使用基于令牌的身份验证而不是基于会话的身份验证有一些很好的理由。
在基于会话的会话中，当然有一个过期时间。因此，如果用户在一段时间内不处于活动状态，他的会话将过期。但在到期之前，如果他向服务器发送请求，他的时间将被延长。
这里有一个很棒的教程 关于JWT.我有一个关于令牌到期时间的问题。假设我们将过期时间设置为 100 秒，然后对令牌进行签名。用户是否处于活动状态并不重要。100 秒后，该令牌将不再有效。这困扰着用户。有什么办法可以延长时间吗？
这是一种真正的方法，还是我有一个错误。知道吗？
如果我正确理解了这个问题，那么在创建过程中更改 JWT 令牌的过期时间相当简单......
"exp"(过期时间)声明标识过期时间 或之后不得接受 JWT 进行处理。 这 处理"EXP"索赔要求当前日期/时间 必须在"exp"索赔中列出的到期日期/时间之前。
更多信息可以在这里找到 https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4
基本上，exp键采用 unix 时间戳 - 将时间戳设置为从现在起> 100 秒，您将完成目标。
要"刷新"令牌，API 需要一个服务，该服务接收有效的 JWT，并返回具有更新过期时间的相同签名 JWT。
静默刷新 我们基于 JWT 的应用程序的用户仍将面临 2 个主要问题：
鉴于我们在 JWT 上的到期时间较短，用户将每 15 分钟注销一次。这将是一次相当可怕的经历。理想情况下，我们可能希望我们的用户长时间登录。 如果用户关闭其应用并再次打开，则需要重新登录。他们的会话不会持久化，因为我们没有将 JWT 令牌保存在客户端上的任何地方。 为了解决此问题，大多数 JWT 提供程序都提供刷新令牌。刷新令牌具有 2 个属性：
它可用于进行 API 调用(例如/refresh_token)，以便在上一个 JWT 过期之前获取新的 JWT 令牌。 它可以安全地跨客户端上的会话持久化！
这里是哈苏拉博客的精彩展览--> https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
您没有提供更多信息，但我假设您将使用 JWT 进行 Web 浏览器身份验证。 您可以将 JWT 保存在具有httpOnly和secure属性的 cookie 中，并将 cookie 过期时间设置足够长(可能是 1 年)，并在 JWT 内部claimsexp属性设置为更短的时间(可能是 1 周或其他时间)。现在，在每个请求中，cookie 都会发送到服务器，以便您可以检查过期时间。 像这样：
if(decodedJwt.exp < Date.now()){
//token is valid, do your stuff
}else {
//token expired, regenerate it and set it to the cookie
//also update the expire time of the cookie
}