我想对我们的新的REST API实现基于JWT的身份验证。但是由于到期在令牌中设置，是否可以自动延长它？我不希望用户在每个X分钟后需要登录，如果他们正在该期间积极使用应用程序。这将是一个巨大的用户体验失败。
但延长到期将创建一个新的令牌(并且旧的令牌仍然有效，直到它过期)。并且在每个请求之后生成新令牌对我来说听起来很蠢。听起来像一个安全问题，当多个令牌同时有效时。当然，我可以使用黑名单来废除旧的旧的，但我需要存储的令牌。 JWT的好处之一是没有存储。
我发现Auth0如何解决它。它们不仅使用JWT令牌，还使用刷新令牌：
https://docs.auth0.com/refresh-token
但是，再次，实现这个(没有Auth0)我需要存储刷新令牌并保持其到期。那么真正的好处是什么呢？为什么不只有一个令牌(不是JWT)并保持在服务器上的到期？
还有其他选择吗？使用JWT不适合这种情况吗？
我在Auth0工作，我参与了刷新令牌功能的设计。
这一切都取决于应用程序的类型，这里是我们推荐的方法。
Web应用程序
一个好的模式是在令牌过期之前刷新令牌。
将令牌过期设置为一周，并在每次用户打开Web应用程序和每一小时刷新令牌。如果用户打开应用程序超过一周，他们将必须再次登录，这是可接受的Web应用程序UX。
要刷新令牌，您的API需要一个新的端点，该端点接收有效的未过期的JWT，并返回带有新到期字段的相同的签名JWT。然后Web应用程序将令牌存储在某个地方。
移动/本地应用程序
大多数本机应用程序只做一次登录一次。
想法是刷新令牌永不过期，它可以被交换总是一个有效的JWT。
从不过期的令牌的问题是永远不会永远不会。如果你失去了手机，你该怎么办？因此，它需要由用户以某种方式可识别，并且应用需要提供一种撤销访问的方式。我们决定使用设备的名称，例如“maryo的iPad”。然后，用户可以去应用程序并撤销对“maryo的iPad”的访问。
另一种方法是在特定事件上撤销刷新令牌。一个有趣的事件是更改密码。
我们认为JWT对这些用例没有用，所以我们使用一个随机生成的字符串，我们将它存储在我们这边。
