身份验证：JWT使用与会话

Question

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

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

Answer 1

我有一个类似的问题，在JWT和令牌缓存之间进行选择以进行用户身份验证。

读完这些文章后，我很清楚，JWTpromise的好处并没有超过它带来的问题。所以令牌缓存（Redis/Memcached）是我的选择。

Auth Headers vs JWT vs Sessions-如何为API选择正确的Auth技术

API的身份验证技术

停止在会话中使用jwt

Answer 2

简短的回答是：没有。

更长的版本是：

在阅读了GraphQL文档中的建议后，我实现了会话管理的JWTs：

如果您不熟悉这些身份验证机制中的任何一种，我们建议使用Expres-jwt，因为它很简单，不会牺牲任何未来的灵活性。

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

停止在会话中使用JWT

Answer 3

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

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

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

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

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

• 安全地存储令牌

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

JWT尤其解决了最后一个问题。它可能有助于理解什么是JWT：

这是一点信息。对于用户会话，您可以包含用户名和令牌到期的时间。但可以想象它可以是任何东西，甚至会话ID或用户的整个配置文件（请不要这样做）。它有一个安全签名，可以防止恶意方生成虚假令牌（您需要访问服务器的私钥才能对它们进行签名，并且您可以验证它们在签名后没有被修改）。您在每次请求时都会发送它们，就像发送cookie或AuthorationHeader一样。事实上，它们通常在HTTPAuthoration标头中发送，但使用cookie也很好。

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

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

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

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

使用JWT令牌的另一个好处是，使用可能以您期望拥有的每种语言提供的库来实现相当容易。它也完全脱离了您最初的用户身份验证方案——如果您转向基于指纹的系统，您不需要对会话管理方案进行任何更改。

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

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

>

防篡改客户端声明。

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

JWT周围存在许多负面因素，但是如果您实现与其他类型的身份验证相同的安全性，您会没事的。

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