我想对我们的新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在这些用例中没有用,因此我们使用随机生成的字符串并将其存储在自己的一边。