关于 JWT（JSON Web Tokens）的一切，以及为什么它比传统的会话管理更强大？

在使用任何后端框架时，我相信你一定听说过JWT（JSON Web Tokens）这个反复出现的术语。在过去几天里，我一直在研究我的全栈 MERN 项目
， 并试图更深入地了解这个概念，所以我想为什么不分享一些见解，这或许也能帮助社区中的其他开发者呢？

那么，让我们开始吧，直奔主题：

JWT（JSON Web Token）本质上是一个用于客户端/主机/用户授权的令牌，请注意，它是用于授权的，而不是用于身份验证的。这两个术语之间存在着细微的差别。

让我们花点时间来理解这两个术语吧。

让我们以我们日常生活中都会用到的Facebook为例：

这是 Facebook 登录页面，请在此处输入您的凭据（用户名和密码），然后点击登录。

当您成功登录并被重定向到新闻源主页时，就可以说您已通过后端服务器的身份验证。

现在，既然我们已经了解了身份验证，接下来让我们了解授权。

假设您想更新 Facebook 上的个人资料照片。您已经知道自己是已认证用户，所以 Facebook 服务器会将您重定向到主页。但是，要更新 Facebook 上的个人资料照片，您必须是授权用户。

在此上下文中，“已授权”指的是您必须拥有相应的访问权限，以确保 Facebook 服务器接受您的请求，从而更新您在 Facebook 上的个人资料图片。

现在的问题是，Facebook 如何知道我是授权用户，并能成功更新我在 Facebook 上的个人资料图片。

它通过 JWT（JSON Web Token Only）来识别它。让我们看看它是如何做到的：

在上图中，你可以看到两幅图。第一幅图描述了传统会话管理的工作原理，第二幅图描述了JSON Web Token情况下授权和身份验证的过程。

让我们来看看目前为止的第二个流程：

步骤 1：在初始步骤 1 中，客户端尝试使用其凭据登录。

步骤 2：在步骤 1 中登录并成功通过身份验证后，后端生成一个 JWT 令牌，并将其与密钥（仅在后端服务器端生成）一起嵌入，然后将该令牌发送回客户端/浏览器。

我们不妨也花一分钟时间分析一下JWT的结构：

如果您看一下左侧，会发现令牌经过编码，仔细观察，会发现这个令牌由三个部分组成。这三个部分如下：

1）头部
2）有效载荷
3）签名

头部部分：
正如您在屏幕录像中看到的那样，头部包含有关令牌编码算法类型（通常是 HS256）和令牌类型的信息。

有效载荷部分：
有效载荷部分是主要部分，其中包含向服务器发出请求的客户端的详细信息，以便服务器知道该客户端确实是授权用户，并且拥有访问技术上称为受保护路由的权限。

有效载荷是一个JavaScript 对象

签名部分

我认为签名部分才是真正发挥作用的地方。后端服务器正是在这里获知，
试图访问受保护路由的用户身份，以及是否应该授予其访问权限。

那么，服务器是如何识别这一点的呢？

当客户端访问受保护的路由时，我们知道除了请求之外，还会发送令牌，令牌中包含有关用户的详细信息，这些信息编码在令牌本身中。

为了识别用户是否已获得授权，服务器会检查请求中收到的令牌是否被客户端篡改。如果发现令牌已被篡改，则立即拒绝该请求。

这就是使用令牌进行授权的过程。

现在，我们来看问题的第二部分，即为什么这种基于令牌的授权方式比传统的会话管理更强大。

假设您有一个应用程序和两台服务器（第一台是主服务器，第二台是辅助服务器）。如果一台服务器上的流量负载达到阈值，所有请求都会被重定向到辅助服务器。如果我们使用传统的会话管理方式，那么被重定向到辅助服务器的用户将无法访问受保护的路由。

原因是，在传统的会话管理中，与用户相关的数据会以会话 ID 的形式存储在浏览器的 Cookie 中，而由于第二个服务器不是主服务器，因此所有授权请求都会被拒绝。

以上就是关于使用令牌和传统会话管理进行授权流程的全部内容。

我希望这篇文章能对您有所帮助。如果您喜欢，请分享给社区里的其他开发者，让他们也能从中受益。谢谢！