JWT分布式鉴权认证授权与权限测试 - 第1节
1.1 什么是JWT
JWT（JSON Web Token）是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑且自包含的方式安全传输信息。JWT 通常用于身份认证和信息交换，尤其在分布式系统、微服务架构和前后端分离场景中，已成为主流的鉴权方案。
JWT 的核心特点在于“自包含”：令牌本身携带了用户身份、权限声明、过期时间等必要信息，服务端无需维护会话状态即可完成验证。这使得 JWT 天然适合无状态、水平扩展的分布式架构。
关键特性：
- 紧凑（Compact）： 体积小，可通过 URL、POST 参数或 HTTP Header 快速传输。
- 自包含（Self-contained）： 载荷中直接包含用户信息，减少数据库查询。
- 防篡改（Tamper-proof）： 通过签名机制保证数据完整性。
1.2 JWT的组成结构
一个完整的 JWT 由三部分组成，以点号（.）分隔：Header.Payload.Signature。下面通过一张结构图直观展示其组成关系。
1.2.1 Header（头部）
Header 通常包含两部分信息：令牌类型（typ）和签名算法（alg）。常见的签名算法包括 HMAC SHA256（HS256）、RSA SHA256（RS256）等。
{
"alg": "HS256",
"typ": "JWT"
}1.2.2 Payload（载荷）
Payload 是 JWT 的核心数据部分，包含声明（Claims）。声明分为三类：
| 声明类型 | 说明 | 示例 |
|---|---|---|
| 注册声明（Registered Claims） | 预定义的标准字段，如 iss（签发者）、sub（主题）、exp（过期时间） | "exp": 1718000000 |
| 公共声明（Public Claims） | 自定义字段，需在 IANA 注册或使用命名空间避免冲突 | "role": "admin" |
| 私有声明（Private Claims） | 双方约定的自定义数据，不强制注册 | "dept": "engineering" |
安全提示：Payload 仅经过 Base64Url 编码，并未加密。切勿在 Payload 中存放密码、密钥等敏感信息。如需加密，应使用 JWE（JSON Web Encryption）。
1.2.3 Signature（签名）
签名由 Header 中指定的算法生成，用于验证消息在传输过程中未被篡改。以 HMAC SHA256 为例，签名生成过程如下：
// 伪代码示例
signature = HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret_key
)服务端收到 JWT 后，使用相同的密钥和算法重新计算签名，并与令牌中的签名比对。若不一致，则拒绝请求。
1.3 JWT与Session的区别
在传统 Web 应用中，Session 是主流的会话管理方式；而在分布式、微服务架构中，JWT 逐渐成为更优选择。下表从多个维度对比两者的核心差异：
| 对比维度 | Session | JWT |
|---|---|---|
| 存储位置 | 服务端内存/数据库/Redis | 客户端（浏览器/移动端） |
| 状态特性 | 有状态：服务端保存会话数据 | 无状态：服务端不保存会话数据 |
| 扩展性 | 需共享 Session（如 Redis 集中存储） | 天然支持水平扩展，无需共享存储 |
| 跨域支持 | 受限于 Cookie 同源策略 | 通过 HTTP Header 轻松跨域 |
| 安全性 | 依赖 Cookie 的 HttpOnly/Secure 属性 | 依赖签名验证，防篡改 |
| 性能 | 每次请求需查询 Session 存储 | 本地验证签名，无需远程查询 |
| 令牌失效 | 服务端可主动销毁 Session | 需等待过期或维护黑名单 |
下面通过一张流程图对比两种鉴权模式在典型请求中的处理路径：
选型建议：
- 单体应用、内网系统：Session 方案成熟，管理简单。
- 微服务、分布式系统、前后端分离：JWT 无状态特性更利于扩展。
- 需要服务端主动踢人、实时失效：Session 更灵活；JWT 需配合黑名单或短过期+刷新令牌策略。