我想对我们的新 REST API 实施基于 JWT 的身份验证。但是既然token里设置了过期时间，那么是否可以自动延长呢？如果用户在这段时间内积极使用该应用程序，我不希望他们需要在每 X 分钟后登录一次。这将是一个巨大的用户体验失败。
但是延长过期时间会创建一个新令牌（旧令牌在过期之前仍然有效）。在每次请求后生成一个新的令牌对我来说听起来很愚蠢。当多个令牌同时有效时，听起来像是一个安全问题。当然，我可以使用黑名单使旧的旧的使用的无效，但我需要存储令牌。 JWT 的好处之一就是无需存储。
我发现Auth0是如何解决的。他们不仅使用 JWT 令牌，还使用刷新令牌：https://auth0.com/docs/tokens/refresh-tokens https://auth0.com/docs/tokens/refresh-tokens
但同样，要实现此功能（无需 Auth0），我需要存储刷新令牌并维护其过期时间。那么真正的好处是什么？为什么不只有一个令牌（不是 JWT）并将过期时间保留在服务器上？
还有其他选择吗？使用 JWT 不适合这种情况吗？
我在 Auth0 工作，参与了刷新令牌功能的设计。
这完全取决于应用程序的类型，这是我们推荐的方法。
网络应用程序
一个好的模式是在令牌过期之前刷新令牌。
将令牌过期时间设置为一周，并在用户每次打开 Web 应用程序时以及每隔一小时刷新一次令牌。如果用户超过一周没有打开应用程序，他们将不得不再次登录，这是可接受的 Web 应用程序用户体验。
要刷新令牌，您的 API 需要一个新端点，该端点接收有效且未过期的 JWT，并返回带有新过期字段的相同签名 JWT。然后 Web 应用程序会将令牌存储在某处。
移动/本机应用程序
大多数本机应用程序都会登录一次且仅登录一次。
这个想法是刷新令牌永远不会过期，并且可以始终将其交换为有效的 JWT。
永不过期的令牌的问题在于never意思是从不。如果你丢了手机你该怎么办？因此，用户需要以某种方式识别它，并且应用程序需要提供一种撤销访问权限的方法。我们决定使用设备的名称，例如“玛丽的iPad”。然后，用户可以转到该应用程序并撤销对“maryo's iPad”的访问。
另一种方法是撤销特定事件的刷新令牌。一个有趣的事件是更改密码。
我们认为 JWT 对于这些用例没有用处，因此我们使用随机生成的字符串并将其存储在我们这边。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
