我希望对新的REST API实现基于jwt的身份验证。但是由于到期时间是在令牌中设置的，那么是否可以自动延长它呢?我不希望用户每隔X分钟就需要登录一次，如果他们在这段时间内积极使用应用程序的话。这将是一个巨大的用户体验失败。
但是延长过期时间会创建一个新的令牌(旧的令牌在过期前仍然有效)。在每个请求后生成一个新的令牌对我来说听起来很傻。当多个令牌同时有效时，听起来像是一个安全问题。当然，我可以使用黑名单使旧的使用无效，但我需要存储令牌。JWT的好处之一是没有存储空间。
我发现Auth0是如何解决这个问题的。他们不仅使用JWT令牌，还使用refresh令牌: https://auth0.com/docs/tokens/refresh-tokens
但是，要实现这一点(没有Auth0)，我需要存储刷新令牌并维护它们的过期。那么真正的好处是什么呢?为什么不只有一个令牌(不是JWT)并将过期时间保存在服务器上呢?
还有其他选择吗?使用JWT不适合这种情况吗?
当前回答
这个方法怎么样:
对于每个客户端请求，服务器将令牌的过期时间与(currentTime - lastAccessTime)进行比较。 如果expirationTime < (currentTime - lastAccessedTime)，则将上一次lastAccessedTime更改为currentTime。 如果浏览器上的不活动时间超过了过期时间，或者如果浏览器窗口被关闭并且过期时间为> (currentTime - lastAccessedTime)，那么服务器可以使令牌过期并要求用户再次登录。
在这种情况下，刷新令牌不需要额外的端点。 将感激任何反馈。
其他回答
问得好——问题本身包含了丰富的信息。
文章“刷新令牌:何时使用它们以及它们如何与jwt交互”为这种场景提供了一个很好的想法。一些要点是:-
刷新令牌携带获取新访问所需的信息 令牌。 刷新令牌也会过期，但寿命相当长。 刷新令牌通常需要严格的存储要求 确保它们不会泄露。 它们还可以被授权服务器列入黑名单。
也可以看看auth0/angular-jwt angularjs
用于Web API。在AngularJS应用程序中启用OAuth刷新令牌使用ASP .NET Web API 2和Owin
参考-刷新过期的JWT示例
另一种替代方法是，一旦JWT过期，用户/系统将调用 另一个url suppose /refreshtoken。与此请求一起通过的还有过期的JWT。服务器会返回一个新的JWT供用户/系统使用。
另一种使jwt失效的解决方案是在用户表上实现一个新的jwt_version整数列，而不需要在后端进行任何额外的安全存储。如果用户希望注销或过期现有令牌，他们只需增加jwt_version字段。
在生成一个新的JWT时，将jwt_version编码到JWT有效负载中，如果新的JWT应该替换所有其他JWT，则可以选择提前增加该值。
在验证JWT时，jwt_version字段将与user_id进行比较，只有匹配时才授予授权。
实际上，我使用Guzzle客户端在PHP中实现了这一点，为api制作了一个客户端库，但这个概念应该适用于其他平台。
基本上，我发行了两个代币，一个短的(5分钟)，一个长的，一周后到期。如果客户机库接收到对某个请求的401响应，则使用中间件尝试对短令牌进行一次刷新。然后，它将再次尝试原始请求，如果它能够刷新，就会获得正确的响应，对用户透明。如果失败了，它会把401发给用户。
如果短令牌过期了，但仍然是可信的，而长令牌是有效且可信的，它将使用长令牌验证的服务上的一个特殊端点刷新短令牌(这是它唯一可以用于的事情)。然后，它将使用短令牌来获得一个新的长令牌，从而在每次刷新短令牌时将其延长一周。
这种方法还允许我们在最多5分钟内撤销访问，这对于我们的使用是可以接受的，而不必存储令牌黑名单。
后期编辑:在我脑海中记忆犹新的几个月后重新阅读这篇文章，我应该指出，你可以在刷新短令牌时撤销访问权，因为它为更昂贵的调用提供了机会(例如调用数据库来查看用户是否已被禁止)，而无需为每一次对你的服务的调用付费。
这个方法怎么样:
对于每个客户端请求，服务器将令牌的过期时间与(currentTime - lastAccessTime)进行比较。 如果expirationTime < (currentTime - lastAccessedTime)，则将上一次lastAccessedTime更改为currentTime。 如果浏览器上的不活动时间超过了过期时间，或者如果浏览器窗口被关闭并且过期时间为> (currentTime - lastAccessedTime)，那么服务器可以使令牌过期并要求用户再次登录。
在这种情况下，刷新令牌不需要额外的端点。 将感激任何反馈。
