使用数据库会话令牌系统，我可以使用用户名/密码进行用户登录，服务器可以生成令牌（例如uuid）并将其存储在数据库中并将该令牌返回给客户端。来自其上的每个请求都将包含令牌，服务器将查询令牌是否有效以及它属于哪个用户。
使用JWT，由于服务器上保留的密钥和客户端保留并随每个请求发送的签名令牌的组合，因此无需为会话/令牌保存任何数据库。
这很好，但除了保存数据库之外，还要检查每个请求（因为它只是检查哈希表，这会很快），我不清楚使用JWT的优点是什么。你能熟悉这个解释吗？ 让我们忽略Cookie，它特别是如上所述的数据库自定义令牌以及我想要比较和了解其好处的JWT 。
答案 0 :(得分：26)
主要区别在于服务器所需的会话存储大小和查找工作：
在服务器端，JWT在内存（或配置文件）中存储单个密钥 - 称为密钥。该密钥有两个目的，它可以创建新的加密令牌，它的功能就像一个主密钥，可以打开所有锁定 - 或者在现实生活中验证所有令牌。 因此，服务器对身份验证请求的响应速度要快得多，因为如果您有两百万或两百万用户登录并不重要 - 将使用相同数量的记录（一个，该服务器密钥）对所有客户端进行身份验证要求。
将用户会话存储在数据库中的传统身份验证，会在每个用户的数据库中创建一条记录，从而产生多个密钥。 因此，如果您有两百万用户登录，服务器将创建两百万条记录，并且每个客户端请求服务器都需要在数据库中找到相关的会话记录*。
JWT将其留给客户端来存储和处理整个会话/用户对象。它实际上更有意义，因为每个客户端只处理自己的数据，所以它也不会给客户端带来繁重的负担。
至于你在上一段写的内容，它不仅仅是我们在这里保存的db调用。 JWT实际上更加可扩展，因为它具有独立和轻量级的特性，它不会因为auth请求堆积而失败，它允许服务器处理auth跨设备和服务而无需管理会话服务器端。
安全性方面，db会话可以占上风：它们可以更安全因为的延迟，并且在用户注销后也更不容易受到会话劫持的攻击。</ p>
* db存储会话方法可以通过有效缓存和仅在快速键/值服务器（如Redis）中存储会话ID（而不是整个用户对象）进行优化。也就是说，在大多数情况下，我仍然会选择JWT方法而不是db。
答案 1 :(得分：1)
基于Json的令牌（JWT）克服了以下问题：
但是JWT不使用会话，移动没有问题，它不需要CSRF，它也适用于CORS。如果您没有有效的令牌，则无法做任何事情。
此标记存储在客户端本地存储/会话存储中，因此您可以将这些令牌传递给其他客户端，但您必须共享用于生成此JWT的相同凭据。