tl/dr:它们的主要区别在于,与 JWT 不同,刷新令牌可以被
撤销。这使其具有更长的提升时间并满足 JWT“生态系统”的重要需求。此外,我认为在每个请求/响应上同时拥有访问和刷新令牌有点不寻常。他们应该去不同的地方。
JWT 寿命短的原因
想象一下 JWT 的生命周期为 3 个月。在正常使用期间,没有选项可以撤销 JWT。因此,如果 JWT 被盗,那么攻击者将能够在 3 个月内充当受害者(或者在盗窃时令牌生命周期还剩下多长)。这就是 JWT 生命周期保持良好和短暂的原因。
短期 JWT 的问题
但是,由于 JWT 的生命周期很短,因此获取新的 JWT 成为一个问题。如果 JWT 的生命周期只有一天(甚至几个小时),那么您需要一些方法来自动获取一个新的。否则,您将把您的用户赶走,因为当他们必须每天重新登录您的网站几次时,他们会感到恼火。
刷新令牌:短期 JWT 的解决方案
这就是刷新令牌的用武之地。它可用于自动生成新的 JWT。因此,刷新令牌的工作是让用户自动重新登录,这样他们就不必在每次 JWT 过期时重新输入密码。这为用户的生活带来了便利,并在安全性和可用性之间取得了良好的平衡。
保护长期存在的刷新令牌
但是,为什么在 JWT 做不到的情况下拥有可以持续数月的刷新令牌是安全的呢?答案很简单:必须可以撤销刷新令牌,以便服务器不再接受它并且不会向拥有它的人发出新的 JWT。这样,如果攻击者获得了刷新令牌的副本,它可以被撤销,一旦他们的短期 JWT 到期,攻击者将失去所有访问权限。因此,您将使用户的所有刷新令牌无效以响应安全事件:如果系统怀疑刷新令牌被盗,如果用户更改了密码,如果用户更改了他们的电子邮件,等等......
从本质上讲,撤销刷新令牌是您强制用户注销的方式,这是“标准”JWT 无法实现的。
把这一切放在一起
最后,为了完整起见,刷新令牌是可撤销的,而访问令牌不是出于(通常)性能原因。JWT 允许系统验证用户访问权限,而无需实际检查数据库,甚至无需访问用户“表”。这对性能很重要,或者如果没有别的,对开发的容易性很重要。不需要数据库访问的微服务更容易管理。因此,您的微服务可以专门使用无状态 JWT,然后您可以拥有一个单独的身份验证服务器来管理刷新令牌的状态和撤销以及 JWT 生成。在某些情况下,这可能是一种方便的关注点分离。
最后,我认为在每个请求和响应中同时拥有 JWT 和刷新令牌有点不寻常。很可能有系统会这样做,而且它们不一定是错误的,但通常 JWT 伴随着每个授权/身份验证请求,并且刷新令牌只会发送到 Auth 服务器以获取新的 JWT。然而,有些人可能总是发送两者以减轻客户端的一些工作,因为后端服务可能会根据需要使用刷新令牌来获取新的 JWT 并将其发送给客户端,这样客户端就不必手动刷新它.