Session 身份验证：JWT使用与会话

在身份验证等情况下，使用JWTs比使用会话有什么优势

---

它是作为一种独立的方法使用还是在会话中使用？

JWT本身没有使用“会话”的好处。JWT提供了一种在客户端而不是在服务器上维护会话状态的方法

当人们问这个问题时，通常的意思是“使用JWT比使用服务器端会话有什么好处”

对于服务器端会话，您必须将会话标识符存储在数据库中，或者将其保存在内存中，并确保客户端始终访问同一服务器。这两种方法都有缺点。在数据库（或其他集中式存储）的情况下，这将成为一个瓶颈和需要维护的事情——本质上是对每个请求进行额外的查询

使用内存解决方案，您可以限制水平扩展，会话将受到网络问题的影响（客户端在Wifi和移动数据之间漫游，服务器重新启动等）

将会话移动到客户机意味着您删除了对服务器端会话的依赖，但这会带来它自己的一系列挑战

• 安全地存储令牌
• 安全地运输它
• JWT会话有时很难失效
• 相信客户的索赔

这些问题由JWTs和其他客户端会话机制共享

特别是JWT解决了最后一个问题。这可能有助于理解JWT是什么：

这是一点信息。对于用户会话，您可以包括用户名和令牌过期的时间。但它可以是任何东西，甚至会话ID或用户的整个配置文件（请不要这样做）。 它有一个安全的签名，可以防止恶意方生成伪造的令牌（您需要访问服务器的私钥才能对它们进行签名，并且您可以验证它们在签名后没有被修改）。 每个请求都会发送它们，就像发送cookie或

授权

头一样。事实上，它们通常在HTTP

Authorization

头中发送，但使用cookie也可以

令牌已签名，因此服务器可以验证其来源。我们将假定服务器信任其自身的安全签名能力（您应该使用标准库：不要尝试自己这样做，并正确地保护服务器）

关于安全传输令牌的问题，答案通常是通过加密通道（通常是httpS）发送令牌

关于在客户机中安全地存储令牌，您需要确保坏人无法访问它。这（主要）意味着防止来自坏网站的JS读取令牌并将其发送回它们。这是通过使用与缓解其他类型XSS攻击相同的策略来缓解的

如果您需要使JWTs无效，那么肯定有一些方法可以实现这一点。仅为请求终止“其他会话”的用户存储每个用户的历元是一种非常有效的方法，可能已经足够好了。如果应用程序需要每次会话失效，那么可以以相同的方式维护会话ID，“killed tokens”表仍然可以维护为比完整用户表小得多（您只需要保留比允许的最长令牌生存期更新的记录）。因此，使令牌无效的能力部分否定了客户端会话的好处，因为您必须保持会话终止状态。这很可能是一个比原始会话状态表小得多的表，因此查找仍然更有效

使用JWT令牌的另一个好处是，使用可能存在于您期望的每种语言中的库来实现JWT令牌相当容易。它还完全脱离了您最初的用户身份验证方案-如果您使用基于指纹的系统，则无需对会话管理方案进行任何更改

一个更微妙的好处是：因为JWT可以携带“信息”，并且客户可以访问这些信息，所以现在您可以开始做一些聪明的事情了。例如，提醒用户他们的会话将在注销前几天到期，让他们根据令牌中的到期日期选择重新验证。不管你能想象到什么

简言之：JWTs回答了其他会话技术的一些问题和缺点

“更便宜”的身份验证，因为您可以消除DB往返（或者至少有一个小得多的表要查询！），从而实现水平可伸缩性

防篡改客户端声明

虽然JWTs没有解决安全存储或传输等其他问题，但它没有引入任何新的安全问题

JWT存在很多负面影响，但是如果您实现了与其他类型的身份验证相同的安全性，那么就可以了

---

最后一点注意：它也不是Cookies vs Tokens。Cookie是一种存储和传输信息位的机制，也可用于存储和传输JWT令牌。

简短的回答是：无。

较长的版本是：

在阅读了以下内容中的建议后，我实施了会话管理JWTs：

如果您不熟悉这些身份验证机制中的任何一种，我们将 建议使用ExpressJWT，因为它简单而又不牺牲 任何未来的灵活性

实现确实很简单，因为它只增加了一点点复杂性。然而，过了一段时间，我（和你一样）开始想知道它有什么好处。事实证明，就会话管理而言，JWT几乎没有（或者可能没有），这篇博文详细解释了这一点：

---

我的两分钱，在路上加上som