session - 身份验证 : JWT usage vs session

Question

在身份验证等情况下，使用 JWT 比 session 有什么优势？

它是用作独立方法还是在 session 中使用？

Answer 1

JWT 本身没有使用“ session ”的好处。 JWT 提供了一种在客户端而不是在服务器上维护 session 状态的方法。
人们在问这个问题时通常的意思是“使用 JWT 比使用 服务器端 session 有什么好处”。
对于服务器端 session ，您要么必须将 session 标识符存储在数据库中，要么将其保存在内存中并确保客户端始终访问同一服务器。这两者都有缺点。在数据库(或其他集中式存储)的情况下，这成为瓶颈和需要维护的东西——本质上是每个请求都要完成的额外查询。
使用内存解决方案，您可以限制水平扩展，并且 session 将受到网络问题(客户端在 Wifi 和移动数据之间漫游、服务器重新启动等)的影响。
将 session 移动到客户端意味着您消除了对服务器端 session 的依赖，但它会带来一系列挑战。

安全地存储 token 。

安全运输。

JWT session 有时很难失效。

相信客户的主张。

这些问题由 JWT 和其他类似的客户端 session 机制共享。
特别是 JWT，解决了最后一个问题。理解什么是 JWT 可能会有所帮助:
这是一点信息。对于用户 session ，您可以包含用户名和 token 到期时间。但可以想象它可以是任何东西，甚至是 session ID 或用户的整个配置文件(但请不要这样做)。
它有一个安全的签名，可以防止恶意方生成假 token (您需要访问服务器的私钥才能对它们进行签名，并且您可以验证它们在签名后未被修改)。
您随每个请求发送它们，就像 cookie 或 Authorization将发送 header 。实际上，它们通常在 HTTP Authorization 中发送。标题，但使用 cookie 也很好。
token 已签名，因此服务器可以验证其来源。我们将假设服务器信任自己的安全签名能力(您应该使用标准库:不要尝试自己做，并正确保护服务器)。
关于安全传输 token 的问题，答案通常是通过加密 channel 发送，通常是 httpS。
关于在客户端安全地存储 token ，您需要确保坏人无法获得它。这(主要)意味着防止来自不良网站的 JS 读取 token 并将其发送回给他们。这可以使用用于缓解其他类型的 XSS 攻击的相同策略来缓解。
如果您需要使 JWT 失效，肯定有办法实现。仅为请求“终止其他 session ”的用户存储每个用户的 epoch 是一种非常有效的方法，可能已经足够好了。如果一个应用程序需要每个 session 失效，那么可以用同样的方式维护一个 session ID，并且“杀死的 token ”表仍然可以保持比完整的用户表小得多(你只需要保留比用户表新的记录)最长允许的 token 生命周期)。因此，使 token 无效的能力部分否定了客户端 session 的好处，因为您必须保持此 session 终止状态。这很可能是一个比原始 session 状态表小得多的表，因此查找仍然更有效。
使用 JWT token 的另一个好处是，使用可能在您期望拥有的每种语言中可用的库来实现它相当容易。它也完全脱离了您最初的用户身份验证方案 - 如果您转向基于指纹的系统，则无需对 session 管理方案进行任何更改。
一个更微妙的好处:因为 JWT 可以携带“信息”并且这可以被客户端访问，您现在可以开始做一些聪明的事情。例如，提醒用户他们的 session 将在他们注销前几天到期，让他们可以根据 token 中的到期日期重新进行身份验证。随便你能想到的。
简而言之:JWT 回答了其他 session 技术的一些问题和缺点。

“更便宜”的身份验证，因为您可以消除数据库往返(或至少有一个小得多的表要查询!)，这反过来又可以实现水平可扩展性。

防篡改的客户端 claim 。

虽然 JWT 没有回答安全存储或传输等其他问题，但它没有引入任何新的安全问题。
围绕 JWT 存在很多负面影响，但如果您实现与其他类型身份验证相同的安全性，您会没事的。
最后一点:它也不是 Cookies vs Tokens。 Cookies 是一种用于存储和传输信息位的机制，也可用于存储和传输 JWT token 。