JWT（JSON Web令牌）自动延长到期日期

2018-05-30 06:36:38

我想为我们的新REST API实施基于JWT的认证。但是由于到期是在令牌中设置的，是否有可能自动延长它？我不希望用户每隔X分钟后都需要登录，前提是他们在那段时间内正在积极使用该应用程序。这将是一个巨大的用户体验失败。

但延长到期时间会创建一个新的标记（旧标记在到期前仍然有效）。每次请求后生成一个新的令牌听起来很愚蠢。听起来像是一个安全问题，当多个标记同时有效时。当然，我可以使用黑名单使旧使用的无效，但我需要存储令牌。 JWT的好处之一是没有储存空间。

我发现Auth0如何解决它。他们不仅使用JWT令牌，而且还使用刷新令牌：https：//docs.auth0.com/refresh-token

但是，为了实现这个（没有Auth0），我需要存储刷新令牌并保持其到期。那么真正的好处是什么？为什么不只有一个令牌（不是JWT）并在服务器上保持到期？

还有其他选择吗？是否使用JWT不适合这种情况？

我在Auth0工作，并参与了刷新令牌功能的设计。

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

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

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

要刷新令牌，您的API需要一个新端点来接收有效的，未过期的JWT，并将带有相同签名的JWT与新的过期字段一起返回。然后，Web应用程序将在某处存储令牌。

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

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

永不过期的令牌的问题永远不意味着永远不会。如果你丢失手机，你会怎么做？因此，它需要以某种方式由用户识别，并且应用程序需要提供撤销访问的方式。我们决定使用设备的名称，例如“maryo's iPad”。然后用户可以去应用程序并撤消对“maryo's iPad”的访问。

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

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

在你自己处理auth的情况下（即不要使用像Auth0这样的提供者），以下方法可能会起作用：

发行相对较短的JWT令牌，比如15分钟。

应用程序在任何需要令牌的交易（令牌包含到期日期）之前检查令牌过期日期。如果令牌已过期，那么它首先要求API'刷新'令牌（这对UX来说是透明的）。

API获取令牌刷新请求，但首先检查用户数据库以查看是否已针对该用户配置文件设置了“reauth”标志（令牌可包含用户标识）。如果该标志存在，则令牌刷新被拒绝，否则发出新的令牌。

重复。

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

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

当我们将应用程序移动到后端的RESTful API中的HTML5时，我正在琢磨着什么。我提出的解决方案是：

在成功登录后，客户端将获得会话时间为30分钟（或任何通常的服务器端会话时间）的令牌。

创建客户端计时器来调用服务，以在其过期时间之前更新令牌。新令牌将取代未来呼叫中的现有令牌。

正如你所看到的，这减少了频繁的刷新令牌请求。如果用户在更新令牌调用被触发之前关闭浏览器/应用程序，则以前的令牌将及时过期，用户将不得不重新登录。

可以实施更复杂的策略来迎合用户的不活动（例如忽略打开的浏览器选项卡）。在这种情况下，更新令牌调用应该包括预期的到期时间，该时间不应超过定义的会话时间。应用程序将不得不跟踪最后一次用户交互。

我不喜欢设置长期过期的想法，因此这种方法可能不适用于需要较低频率验证的本地应用程序。

链接地址: http://www.djcxy.com/p/3745.html