从单体到分布式：JWT 如何彻底改变 Web 认证系统

[一、传统单体应用的认证：Session+Redis 方案](#一、传统单体应用的认证：Session+Redis 方案)

[1.1 工作流程详解](#1.1 工作流程详解)

[1.2 存在的致命问题](#1.2 存在的致命问题)

二、分布式系统带来的认证挑战

[三、JWT 认证方案详解](#三、JWT 认证方案详解)

[3.1 什么是 JWT？](#3.1 什么是 JWT？)

[3.2 JWT 的结构](#3.2 JWT 的结构)

[3.3 JWT 在分布式系统中的工作流程](#3.3 JWT 在分布式系统中的工作流程)

[四、传统 Session 认证 vs JWT 认证：全面对比](#四、传统 Session 认证 vs JWT 认证：全面对比)

[五、JWT 的最佳实践和安全注意事项](#五、JWT 的最佳实践和安全注意事项)

六、总结

在现代 Web 开发中，用户认证是每个应用不可或缺的核心功能。从早期的单体应用到如今盛行的微服务架构，认证系统的实现方式也经历了重大变革。今天，我们将深入探讨传统 Session 认证与 JWT（JSON Web Token）认证的本质区别，以及为什么分布式系统几乎都选择了 JWT 作为标准认证方案。

一、传统单体应用的认证：Session+Redis 方案

在单体应用时代，最经典的认证方式就是基于 Session 的会话管理。让我们先回顾一下它的工作原理。

1.1 工作流程详解

当用户登录时，系统会验证用户名和密码，验证通过后生成一个唯一的 Session ID，将用户信息存储在服务器端，并将 Session ID 通过 Cookie 返回给客户端。后续客户端的每次请求都会自动携带这个 Cookie，服务器通过 Session ID 找到对应的用户信息，从而识别用户身份。

随着用户量的增长，单台服务器的内存无法承载所有 Session，于是出现了将 Session 集中存储在 Redis 中的方案：

具体步骤：

用户 A 和用户 B 向 Web 服务器发送包含用户名和密码的登录请求

Controller 层接收请求并转发给 Service 层进行身份验证

验证成功后，生成唯一的 user_Id 作为 key，用户对象作为 value 存储在 Redis 中

将 user_Id 返回给客户端，通常存储在 Cookie 中

后续请求中，客户端携带 userId，服务器从 Redis 中查询用户信息完成认证

1.2 存在的致命问题

这种方案在单体应用中运行良好，但随着系统向分布式架构演进，暴露出了严重的缺陷：

单点故障风险：所有 Session 都存储在一台 Redis 服务器上，一旦这台服务器宕机，整个系统的认证功能将完全瘫痪
硬件成本增加：为了保证高可用，需要搭建 Redis 集群，增加了运维复杂度和硬件成本
跨域问题：Cookie 在跨域场景下会受到限制，无法在多个域名之间共享
扩展性差：在微服务架构中，每个服务都需要连接 Redis 来验证用户身份，增加了服务间的耦合度

二、分布式系统带来的认证挑战

当我们将单体应用拆分为多个微服务（如用户服务、订单服务、购物车服务）时，传统的 Session 认证方案就显得力不从心了。

想象一下这样的场景：用户登录了用户服务，然后访问订单服务。订单服务如何知道这个用户已经登录了呢？如果使用 Session 方案，订单服务需要连接同一个 Redis 服务器来查询用户信息。当服务数量增加到几十个甚至上百个时，这种方式会导致 Redis 成为整个系统的性能瓶颈。

此外，在前后端分离的架构中，前端可能部署在不同的域名下，Cookie 的跨域限制会导致认证失败。移动端应用更是无法使用 Cookie 进行认证。

正是在这样的背景下，JWT 应运而生，成为了分布式系统认证的标准解决方案。

三、JWT 认证方案详解

3.1 什么是 JWT？

JWT（JSON Web Token）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间安全地传输信息作为 JSON 对象。这些信息可以通过数字签名进行验证和信任。

简单来说，JWT 就是一个字符串，它包含了用户的身份信息和权限信息，并且经过了服务器的数字签名。客户端可以将这个字符串存储在本地，每次请求时携带它，服务器只需要验证签名的有效性，就可以确认用户的身份。

3.2 JWT 的结构

一个 JWT 由三部分组成，用点（.）分隔：

复制代码

xxxxx.yyyyy.zzzzz

这三部分分别是：

Header（头部）：包含令牌类型（JWT）和使用的签名算法（如 HS256）
Payload（载荷）：包含声明（Claims），即用户的身份信息和其他数据
Signature（签名）：使用服务器的私钥对 Header 和 Payload 进行签名，防止数据被篡改

示例 JWT：

python 复制代码

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInVzZXJuYW1lIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MTY0MjQwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

3.3 JWT 在分布式系统中的工作流程

JWT 的核心思想是 "服务器不存储状态，客户端存储状态"。服务器只负责生成和验证令牌，不需要存储任何用户会话信息。

具体步骤：

用户向认证系统发送登录请求，包含用户名和密码

认证系统验证用户身份，验证成功后生成 JWT 令牌

将 JWT 令牌返回给客户端，客户端通常存储在 localStorage 或 Pinia/Vuex 等状态管理工具中

当用户访问其他微服务（如订单系统、购物车系统）时，将 JWT 令牌添加到请求头中

中间件（Middleware）拦截请求，从请求头中取出 JWT 令牌

中间件远程调用认证系统验证 JWT 令牌的有效性

如果令牌不存在或无效，返回 401 Unauthorized，要求用户重新登录

如果令牌有效，解析出用户信息和权限信息，进行鉴权操作

鉴权通过后，将请求转发到对应的微服务进行处理

四、传统 Session 认证 vs JWT 认证：全面对比

为了更清晰地理解两种方案的区别，我们通过一个表格进行全面对比：

对比维度	传统 Session+Redis 认证	JWT 认证
服务器状态	有状态，需要存储用户会话信息	无状态，服务器不存储任何会话信息
扩展性	差，所有服务都需要连接 Redis	好，服务之间完全解耦
跨域支持	差，受 Cookie 跨域限制	好，令牌可以通过请求头传递
移动端支持	差，移动端无法使用 Cookie	好，令牌可以存储在本地
单点故障	存在，Redis 宕机导致整个系统不可用	不存在，认证系统可以集群部署
性能	较高，Redis 查询速度快	稍低，需要验证签名和远程调用
安全性	较高，Session ID 不易被篡改	中等，需要注意令牌泄露和过期问题
适用场景	单体应用、同域名下的应用	分布式系统、微服务架构、前后端分离应用

五、JWT 的最佳实践和安全注意事项

虽然 JWT 有很多优势，但如果使用不当，也会带来严重的安全风险。以下是一些最佳实践：

使用 HTTPS：所有请求都应该使用 HTTPS 加密，防止 JWT 在传输过程中被窃取
设置合理的过期时间：JWT 一旦生成，在过期前无法被撤销。因此，应该设置较短的过期时间（如 1 小时），并配合刷新令牌（Refresh Token）使用
不要在 Payload 中存储敏感信息：JWT 的 Payload 是 Base64 编码的，任何人都可以解码查看。绝对不要在 Payload 中存储密码、银行卡号等敏感信息
使用强签名算法：推荐使用 HS256 或 RS256 算法进行签名，不要使用 none 算法
实现令牌撤销机制：虽然 JWT 本身不支持撤销，但可以通过维护一个黑名单来实现令牌撤销功能
限制令牌的使用范围：在 Payload 中添加 aud（受众）和 iss（签发者）声明，限制令牌只能在特定的服务中使用

六、总结

从传统的 Session 认证到现代的 JWT 认证，是 Web 开发从单体架构向分布式架构演进的必然结果。JWT 通过无状态的设计，完美解决了分布式系统中的认证问题，使得服务之间可以独立部署和扩展。

然而，JWT 并不是银弹。在选择认证方案时，我们需要根据实际的业务场景和技术架构来决定。对于简单的单体应用，Session+Redis 方案可能更加简单高效；而对于复杂的分布式系统和微服务架构，JWT 无疑是更好的选择。

希望这篇文章能够帮助你深入理解 JWT 认证的原理和实践。如果你有任何问题或想法，欢迎在评论区留言交流。