1. JWT 基础概念

1.1 什么是 JWT

JWT（JSON Web Token） 是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全传输信息。JWT 通常用于身份认证和信息交换场景，其核心特点是：服务端无需存储会话状态，所有用户身份信息都编码在 Token 本身中。

关键认知： JWT 不是加密协议，而是签名/验签协议。Payload 默认只做 Base64 编码（可被解码读取），完整性由 Signature 保证。如需数据机密性，应在 JWT 外层叠加加密传输（如 HTTPS）。

1.2 JWT 的组成结构

一个完整的 JWT 由三个部分构成，以英文句点 . 分隔：

# JWT 字符串格式
Header.Payload.Signature

# 实际示例（换行仅为展示，真实 JWT 为连续字符串）
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
组成部分 说明 必选
Header（头部） 声明 Token 类型和签名算法，如 {"alg":"HS256","typ":"JWT"} 是
Payload（载荷） 存放实际声明数据（Claims），如用户 ID、角色、过期时间 是
Signature（签名） 对 Header 和 Payload 的签名，防止数据被篡改 是

Header 头部

Header 通常包含两个字段：

  • alg：签名算法，常见值 HS256（HMAC-SHA256）、RS256（RSA-SHA256）
  • typ：Token 类型，固定为 JWT
{
  "alg": "HS256",
  "typ": "JWT"
}

Payload 载荷

Payload 包含三类声明（Claims）：

声明类型 说明 示例
注册声明 预定义的标准字段，如 iss（签发者）、exp（过期时间）、sub（主题） "exp": 1735689600
公共声明 自定义字段，建议在 IANA JSON Web Token Registry 注册或使用命名空间避免冲突 "role": "admin"
私有声明 双方约定的自定义字段，不注册 "user_id": 1001 
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1735689600,
  "role": "admin"
}

Signature 签名

签名由以下公式生成：

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

服务端使用密钥对 Header 和 Payload 进行签名，接收方使用相同密钥验证签名是否匹配。任何对 Header 或 Payload 的篡改都会导致签名验证失败。

安全红线： 永远不要在 Payload 中存放密码、密钥等敏感信息。Payload 仅做 Base64 编码，等同于明文传输。如需敏感数据，请使用 JWE（JSON Web Encryption）或额外加密层。
JWT 结构解析图 Header . Payload . Signature Header 算法 & 类型 alg: HS256 typ: JWT Payload 声明数据 sub: 用户ID exp: 过期时间 Signature 防篡改签名 HMACSHA256 (header.payload, secret) Base64URL 编码后拼接：Header.Payload.Signature 服务端验证签名通过 → 信任 Payload 数据 编码流程 JSON → Base64URL JSON → Base64URL 签名生成

1.3 JWT 与 Session/Cookie 的区别

JWT 和传统的 Session/Cookie 认证机制在状态存储、扩展性、跨域支持等方面存在本质差异。以下从多个维度进行对比：

对比维度 Session / Cookie JWT
状态存储 服务端存储 Session 数据，客户端仅存 Session ID 客户端存储完整 Token，服务端无状态
扩展性 水平扩展需共享 Session（如 Redis），增加运维复杂度 天然支持水平扩展，任何服务节点均可独立验证
跨域支持 受同源策略限制，跨域需额外配置 CORS + 凭证 无跨域限制，Token 放在 HTTP Header 中传递
安全性 Session ID 随机生成，难以伪造；但易受 CSRF 攻击 签名防篡改；但 Token 泄露后攻击者可直接使用
性能 每次请求需查询 Session 存储（I/O 开销） 服务端仅做签名验签（CPU 计算），无 I/O 开销
失效控制 服务端可随时销毁 Session，即时生效 Token 过期前无法主动失效（需黑名单机制辅助）
数据量 Cookie 中仅存 Session ID（通常 32-128 字节） Token 包含完整 Payload，体积较大（通常 500-2000 字节）
选型建议：
  • 单体应用 / 传统 Web： Session/Cookie 更简单，服务端可控性强。
  • 微服务 / 前后端分离 / 移动端： JWT 无状态、跨域友好，更适合分布式架构。
  • 混合方案： 部分场景使用 JWT 做认证，配合 Redis 黑名单实现主动失效。
Session/Cookie vs JWT 认证流程对比 Session/Cookie 流程 客户端 服务端 Session 存储 ① 登录请求 ② 创建 Session ③ 返回 Session ID ④ 请求 + Cookie ⑤ 查询 Session JWT 流程 客户端 服务端 ① 登录请求 ② 生成 JWT ③ 返回 JWT ④ 请求 + JWT ⑤ 验签（无 I/O） 核心差异总结 • Session/Cookie：服务端有状态，需 Session 存储（Redis/DB），扩展需共享状态 • JWT：服务端无状态，Token 自包含，任何节点均可独立验证，天然支持水平扩展 • JWT 无法主动失效，Session 可即时销毁；JWT 跨域友好，Session 受同源策略限制

1.4 何时选择 JWT

根据实际架构需求，以下场景优先考虑 JWT：

  • 前后端分离架构： 前端 SPA / 移动端与后端通过 API 通信，JWT 放在 Authorization Header 中传递，天然支持跨域。
  • 微服务架构： 各服务独立验证 JWT，无需集中 Session 存储，降低服务间耦合。
  • 第三方 API 授权： JWT 可作为 API 访问令牌，携带用户身份和权限信息，方便下游服务做鉴权。
  • 单点登录（SSO）： JWT 作为统一的身份凭证，在多个系统间传递，实现一次登录、多处访问。
避坑提醒： JWT 并非万能方案。如果业务需要服务端主动控制会话失效（如强制下线、账号封禁），纯 JWT 方案需要额外引入黑名单或 Token 版本号机制，此时 Session/Cookie 可能更直接。
← 上一章 📖 返回目录 下一章 →