访问/刷新令牌混淆

Question

我已经阅读了很多关于这个主题的文章，我可以看到，对于使用JWT进行身份验证，有很多不同的观点和方法。

我的理解如下: JWT身份验证机制最简单的形式应该是：

password.

• Create

1. 验证用户名，它是一个签名的JWT访问令牌，包含用户的信息(取决于应用程序的需要)。
2. 在响应中发送该令牌。客户端的
3. 则存储令牌(据我理解，该令牌是否更安全)，并将其与每个请求的头部一起发送。然后，服务器可以通过验证JWT来授权用户中间件。没有状态，包含在JWT.

中的所有信息。

假设JWT没有过期(或者可能是很长的到期日期，可能是几个月)，这听起来不错，因为我可以为用户提供一个长时间的持久登录状态。据我所知，我担心的是，如果JWT被偷，它本质上是一张无限制的出入卡，是一个巨大的安全漏洞。

因此，在刷新令牌进入的地方，服务器同时发出刷新令牌和访问令牌(具有长/无限过期的刷新令牌和短访问令牌)。

服务器数据库保存某种有效的刷新令牌表(这样，如果一个令牌被窃取，它很容易失效)，当发出一个新的访问令牌时，验证刷新令牌。

这还需要在前端添加某种倒计时机制，在访问令牌到期日期之前将刷新请求发送到服务器，这样用户就不会被注销。

我的问题是：

为什么？如果我们经历了为刷新令牌创建db表的所有麻烦，为什么不直接创建一个有效访问令牌的表并在需要时使它们失效呢？怎么会比使用刷新令牌更不安全呢？

谢谢

Answer 1

访问令牌主要不是用来提供额外的安全性，而是提供效率和解耦。

访问令牌可以有很短的生存期--甚至不到一分钟--但是可以用于在这段时间内对不同服务的多个请求进行身份验证。这些服务不需要对身份验证数据库有任何访问权，因为它们可以信任访问令牌，直到其到期为止；这使得它们更快、更简单。

例如，如果您使用的是包含大量AJAX请求的动态页面，这可能会很快地连续运行。这些AJAX调用可以作为无服务器函数(例如AWS Lambda)来实现，或者作为在不同服务器上使用不同编程语言的独立脚本来实现，或者您可能只想使它们尽可能高效，并避免任何数据库访问。他们需要共享的唯一信息是一个公钥来验证他们接收到的JWT上的签名。

从安全性的角度来看，这是一种权衡:一方面，访问被撤销的用户的访问令牌仍然可以使用，直到它过期为止；另一方面，长寿命的刷新令牌比传统的会话令牌传输的要少得多，因此被拦截的机会更少。

为解决您的具体关切：

--这也增加了在前端添加某种倒计时机制的需要，其中将在访问令牌到期日期之前向服务器发送刷新请求，这样用户就不会被注销。

不需要“倒计时”。访问这两个令牌的代码在使用前只需查看其当前访问令牌；如果它已过期或即将过期，它将使用刷新令牌请求一个新的访问令牌。然后，它将获得一个新的访问令牌，可能还会得到一个更新的刷新令牌--刷新令牌上的过期日期表示用户在被自动注销之前可以空闲多久。

Answer 2

我们不需要制作一个访问令牌表，而且安全是危险的。

我们必须只保存刷新令牌，并在表中添加一个有效/无效字段。并向客户端发送访问令牌和刷新令牌。

客户端发送带有每个请求头的访问令牌。

服务器可以使用验证JWT的中间件授权用户。

一段时间后，访问令牌将过期(访问令牌的过期时间比刷新令牌的过期时间短)。客户端向服务器发送刷新令牌。

然后客户端将使用刷新令牌获得新的访问令牌(应该重新创建刷新令牌，换句话说，我们只能使用一次刷新令牌，我们必须用新的刷新令牌更新刷新令牌表)。

客户端可以获得新的访问令牌和刷新令牌。

我希望它能帮助你。