请问JWT(JSONWeb令牌)自动延长到期时间

Question

JWT(JSONWeb令牌)自动延长到期时间我想对我们的新RESTAPI实现基于JWT的身份验证。但是，由于到期是在令牌中设置的，那么是否可以自动延长它呢？如果用户在这段时间内积极使用应用程序，我不希望用户在每隔X分钟注册一次。那将是一个巨大的UX失败。但是延长过期会创建一个新令牌(旧令牌在过期之前仍然有效)。在每次请求之后生成一个新的令牌对我来说听起来很傻。当多个令牌同时有效时，听起来就像是一个安全问题。当然，我可以使用黑名单使旧的已使用的标记失效，但是我需要存储令牌。JWT的好处之一是没有存储。我发现Auth0是如何解决这个问题的。它们不仅使用JWT令牌，还使用刷新令牌：https://docs.auth0.com/refresh-token但是，要实现这个(没有Auth0)，我需要存储刷新令牌并维护它们的过期。那麽，真正的好处是甚麽呢？为什么不只有一个令牌(而不是JWT)并将过期保存在服务器上呢？还有其他选择吗？是否使用JWT不适合此场景？

Answer 1

我在Auth0工作，我参与了刷新令牌特性的设计。

这取决于应用程序的类型，下面是我们推荐的方法。

Web应用

一个好的模式是在令牌到期之前刷新它。

将令牌过期设置为一周，每次用户打开Web应用程序时刷新令牌，每一小时刷新一次。如果用户在超过一周内不打开应用程序，他们将不得不再次登录，这是可以接受的Web应用程序UX。

要刷新令牌，API需要一个新的端点，它接收有效的而不是过期的JWT，并返回与新过期字段相同的签名JWT。然后Web应用程序会将令牌存储在某个地方。

移动/本地应用程序

大多数本地应用程序只登录一次。

这样做的想法是，刷新令牌永远不会过期，并且可以始终将其交换为有效的JWT。

一个永不过期的令牌的问题是绝不可能意味着永远不会。如果你的手机丢了怎么办？因此，它需要被用户以某种方式识别，并且应用程序需要提供一种撤销访问的方法。我们决定使用设备的名称，例如“maryo的ipad”。然后用户可以进入应用程序并撤销对“maryo‘s ipad”的访问。

另一种方法是撤销特定事件的刷新令牌。一个有趣的事件是更改密码。

我们认为JWT对这些用例没有用处，所以我们使用一个随机生成的字符串，并将它存储在自己的一侧。

Answer 2

在您自己处理auth的情况下(即不使用类似于Auth0的提供程序)，以下内容可能有效：

1. 以相对较短的到期时间(例如15分钟)发出JWT令牌。
2. 应用程序在任何需要令牌的事务之前检查令牌过期日期(令牌包含到期日期)。如果令牌已经过期，那么它首先要求API‘刷新’令牌(这是透明地对UX进行的)。
3. API获得令牌刷新请求，但首先检查用户数据库，查看是否针对该用户配置文件设置了“reauth”标志(令牌可以包含用户id)。如果存在标志，则拒绝令牌刷新，否则将发出新令牌。
4. 重复一遍。

例如，当用户重置密码时，数据库后端中的“reauth”标志将被设置。当用户下次登录时，该标志将被移除。

此外，假设您有一个策略，用户必须至少每72小时登录一次。在这种情况下，您的API令牌刷新逻辑还将检查用户从用户数据库中的最后登录日期，并在此基础上拒绝/允许令牌刷新。

Answer 3

当我在后端使用RESTfulAPI将我们的应用程序迁移到HTML 5时，我一直在修补。我想出的解决办法是：

1. 在成功登录时，向客户端发出一个令牌，会话时间为30分钟(或任何通常的服务器端会话时间)。
2. 创建一个客户端计时器来调用服务，以便在令牌到期之前对其进行更新。新令牌将取代未来呼叫中的现有令牌。

如您所见，这减少了频繁的刷新令牌请求。如果用户在触发更新令牌调用之前关闭了浏览器/应用程序，则前一个令牌将过期，用户将不得不重新登录。

可以实施更复杂的策略来满足用户的不活动(例如，忽略了打开的浏览器选项卡)。在这种情况下，更新令牌调用应该包括预期的到期时间，不应超过定义的会话时间。应用程序必须相应地跟踪最后的用户交互。

我不喜欢设置长期过期的想法，因此这种方法在需要较少频繁身份验证的本地应用程序中可能不能很好地工作。