JSON Web令牌（JWT）优于数据库会话令牌

使用数据库会话令牌系统，我可以使用用户名/密码进行用户login，服务器可以生成令牌（例如uuid）并将其存储在数据库中，并将该令牌返回给客户端。其上的每个请求都会包含该令牌，服务器将查找令牌是否有效以及它属于哪个用户。

使用JWT，不需要将会话/令牌相关的任何内容保存到数据库中，这要归功于服务器上保存的密钥和客户端保存并随每个请求一起发送的签名令牌的组合。

这是好的，但除了保存数据库检查每个请求（这将是快速的，因为它只是检查一个哈希表），我不清楚使用JWT的优点是什么。你能熟悉这个解释吗？ 让我们忽略cookie，它是特别的一个数据库自定义令牌如上所述和JWT，我试图比较和理解的好处 。

主要区别在于会话存储大小和服务器所需的查找工作：

在服务器端，JWT将单个密钥存储在内存（或者configuration文件）中 – 称为密钥。该密钥有两个目的，它可以创build新的encryption令牌，并且还可以像“打开所有锁”的主密钥一样运行 – 或者在现实生活中validation所有令牌。因此，服务器对身份validation请求的响应要快得多，因为如果您有两百万或两百万个用户login，则无关紧要 – 将使用相同数量的logging（一个即服务器密钥）来validation所有客户端请求。
将用户会话存储在数据库中的传统身份validation，会在数据库中为每个用户创build一个logging，这会导致多个密钥 。因此，如果您有两百万用户login，服务器将创build两百万条logging，并且每个客户端请求服务器需要在数据库*中find相关的会话logging。

JWT将其留给客户端来存储和处理整个会话/用户对象。这实际上更有意义，因为每个客户端只处理自己的数据，所以也不会给客户端带来沉重的负担。

至于你在最后一段中写的是什么，这不仅仅是我们在这里保存的db调用。 JWT实际上具有更高的可扩展性，因为它具有独立和轻量级的特点，它不会因为auth请求堆积而失败，并且允许服务器处理设备和服务中的auth，而无需pipe理服务器端的会话。

安全方面，数据库会话可以说占了上风：由于这种延迟，它们可以更安全，并且在用户注销后也不易受到会话劫持的攻击。

*数据库存储会话方法可以通过有效的caching进行优化，并且只将会话ID（而不是整个用户对象）存储在快速键/值服务器（如Redis）中。也就是说，在大多数情况下，我仍然会select使用db的JWT方法。

基于Json的令牌（JWT）克服了以下问题：

但JWT不使用会话，对于移动设备没有任何问题，它不需要CSRF，它也可以和CORS一起使用。如果你没有一个有效的标记，你什么也做不了。

当这个令牌在客户端本地存储/会话存储中存储时，还可以将这些令牌传递给其他客户端，但是您必须共享用于生成此JWT的相同凭据。