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