JSON Web令牌(JWT)优于数据库会话令牌
对于数据库会话令牌系统，我可以使用用户名/密码进行用户登录，服务器可以生成一个令牌（例如，uuid)并将其存储在数据库中，然后将该令牌返回给客户机。从上面发出的每个请求都将包括令牌，服务器将查找令牌是否有效以及它属于哪个用户。
使用JWT，就会话/令牌而言，不需要将任何内容保存到数据库中，这要归功于服务器上保存的密钥和客户端保存并随每个请求发送的签名令牌的组合。
这很好，但是除了保存一个数据库之外，检查每个请求（因为它只是检查一个哈希表，所以这会很快），我不清楚使用JWT的优点是什么。你有熟悉这个的人能解释一下吗？让我们忽略cookies，它特别是上面描述的数据库自定义令牌和我试图比较和理解其好处的JWT。
共有1个答案
主要区别是会话存储大小和服务器所需的查找工作：
>
在服务器端，JWT将单个密钥存储在内存中（或配置文件中）--称为秘密密钥。该密钥有两个目的，它可以创建新的加密令牌，它的功能也像一把万能钥匙，可以“打开所有锁”--或者在现实生活中验证所有令牌。因此，服务器对身份验证请求的响应速度要快得多，因为如果您有两二百万用户登录，这并不重要-将使用相同数量的记录（一个服务器密钥）对所有客户端请求进行身份验证。
将用户会话存储在数据库中的传统身份验证会在数据库中为每个用户创建一个记录，从而产生多个密钥。因此，如果有两百万用户登录，服务器将创建两百万条记录，对于每个客户端请求，服务器都需要在数据库中找到相关的会话记录*。
不过，从安全性角度来看，db会话可以说是占上风：由于延迟，它们可以更安全，并且在用户注销后更不易受到会话劫持的攻击。
*db stored sessions方法可以通过有效的缓存和在快速键/值服务器（如Redis）中仅存储会话id（而不是整个用户对象）来优化。尽管如此，对于大多数情况，我仍然会选择JWT方法而不是db方法。
-
Stormpath 中有很多博客文章讨论了您应该如何使用 cookie 而不是 sessionStorage/localStorage 来存储您的 JWT： https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage https://stormpath.com/blog/token-auth-sp
-
问题内容： 我正在使用Java和AngularJS开发一个Web应用程序，并选择实现令牌身份验证和授权。出于练习目的，我到达了将凭证发送到服务器，生成随机令牌存储凭证并将其发送回客户端的地步。在对服务器的每个请求中，我都将令牌附加在标头中，并且可以完美运行。对于身份验证的观点是完美的，不需要更多。 但是，我现在想跟踪用户类型（管理员，普通用户…），它的ID或任何其他唯一字段；据我了解，我必须使用登
-
我正在构建一个使用JWT进行身份验证的应用程序。我开始做一些研究，但对于诸如刷新令牌和令牌存储之类的主题缺乏共识，我感到惊讶。 据我所知，JWT和OAuth是两个不同的协议，它们遵循不同的规范。 但我的问题是，对于一个没有通过第三方资源服务器如Google、Facebook等认证的应用程序，有一个刷新令牌真的有用吗？为什么不让JWT令牌像刷新令牌一样持续时间长。 另一方面，我可以看到，如本文所述，
-
我们正在使用JWT Nuget来创建和验证令牌。下面是我们用来创建令牌的代码 我的理解是，这不会加密令牌，因为我能够通过访问jwt.io解析令牌，并且能够读取内容。我想加密令牌，这样它就不应该被解析。我在JWT Nuget中找不到任何可以加密令牌的方法。 那么如何使用JWT nuget对令牌进行签名和加密呢？ 编辑： 我知道JWT不需要任何加密，因为只有经过身份验证的用户才能读取令牌，这意味着，我
-
我已经验证了JWT令牌，它在会话存储中。 计算机1以普通用户身份登录计算机2以管理员身份登录 如果我在会话存储中将机器1 jwt令牌替换为机器2，并且如果我进一步调用api，服务器应该说未经授权的访问。
-
这是我的身份验证流程： 用户登录后收到两个令牌（具有过期时间的访问令牌和没有过期时间的刷新令牌） 对于每个用户，刷新令牌存储在数据库中名为refreshTokens的json列中（这是一个数组） 在客户端，访问令牌和刷新令牌都存储在本地存储器上 当需要验证用户时，如果访问令牌过期，将使用刷新令牌创建一个新的访问令牌，并将其发送回用户并保持用户登录 当用户注销时，数据库中存储的刷新令牌（在refre