JWT认证授权契约领域建模与架构设计 - 第1节

1.1 JWT 定义与本质

JSON Web Token（JWT） 是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全传输声明信息。JWT 的核心价值在于：将用户身份与授权信息编码为一个独立的令牌，服务端无需维护会话状态即可完成认证与授权。

关键特性：JWT 是“自包含”的——令牌本身携带了所有必要的用户信息与元数据，服务端只需验证令牌签名即可信任其内容，无需查询数据库或会话存储。

JWT 的结构组成

一个完整的 JWT 由三个 Base64URL 编码的部分组成，以点号（.）分隔：

# JWT 格式示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
部分 名称 内容说明
Header 头部 令牌类型（typ）与签名算法（alg），如 HS256、RS256
Payload 载荷 声明（Claims）：用户身份、权限、过期时间等业务数据
Signature 签名 对 Header 和 Payload 的防篡改校验值
注意：Payload 仅经过 Base64URL 编码，并未加密。任何持有令牌的人都可以解码读取其中的内容。切勿在 Payload 中存放密码、密钥等敏感信息。
JWT 令牌结构分解 Header（头部） {"alg":"HS256", "typ":"JWT"} Payload（载荷） {"sub":"123456", "name":"John","iat":1516239022} Signature（签名） HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 三部分通过点号（.）拼接：Header.Payload.Signature

1.2 JWT 与传统 Session 认证的区别

传统 Session 认证采用“服务端存储会话”模式，而 JWT 采用“客户端持有令牌”模式。两者在架构、扩展性、安全性方面存在本质差异。

对比维度 传统 Session 认证 JWT 认证
状态存储 服务端内存/Redis 存储 Session 客户端存储令牌，服务端无状态
扩展性 需要共享 Session 存储（如 Redis 集群） 天然支持水平扩展，无需共享存储
跨域支持 受限于 Cookie 同源策略 通过 Authorization 头，天然支持跨域
性能开销 每次请求需查询 Session 存储 仅需验证签名，无需查询外部存储
令牌失效 服务端可立即删除 Session 需配合黑名单或短有效期实现
数据体积 Session ID 很小（通常 32 字节） JWT 体积较大（通常 500 字节以上）
架构决策提示：如果系统需要服务端主动撤销用户权限（如强制下线、权限变更），传统 Session 更易实现；如果系统追求无状态、高扩展、跨域微服务架构，JWT 是更优选择。
Session 认证 vs JWT 认证流程对比 传统 Session 认证 客户端 服务端 Session 存储 1. 登录请求 2. 创建 Session 3. 返回 Session ID 4. 请求携带 Session ID 5. 查询 Session JWT 认证 客户端 服务端 1. 登录请求 2. 返回 JWT 本地存储 JWT 3. 请求携带 JWT（Authorization 头） 验证签名 Session 认证：服务端维护会话状态，每次请求需查询存储 JWT 认证：服务端无状态，仅验证签名即可信任令牌内容

1.3 JWT 的典型应用场景

JWT 因其无状态、跨域友好、自包含的特性，在以下场景中得到广泛应用：

  • 单点登录（SSO）：JWT 作为统一的身份令牌，在多个子系统间传递，用户只需登录一次即可访问所有信任的应用。
  • 前后端分离架构：前端 SPA 或移动端通过 Authorization 头携带 JWT 访问后端 API，后端无需维护 Session，天然支持跨域。
  • 微服务网关认证：API 网关验证 JWT 后将用户身份信息透传给下游服务，下游服务无需重复认证。
  • 移动端认证：移动端不依赖 Cookie，JWT 可安全存储在本地存储或 Keychain 中，适合无状态 API 调用。
  • 第三方 API 授权：JWT 可作为 Bearer Token 授权第三方应用访问受保护的 API 资源。
场景选择原则：当系统需要无状态、跨域、高扩展性时，优先考虑 JWT；当系统需要服务端主动撤销令牌、精细会话管理时，需结合短有效期 + 刷新令牌机制或回退到 Session 方案。

JWT 在微服务架构中的典型流程

  1. 用户向认证服务提交凭证（用户名/密码）。
  2. 认证服务验证成功后，生成 JWT 并返回给客户端。
  3. 客户端将 JWT 存储在本地（localStorage / 移动端安全存储）。
  4. 客户端每次请求 API 时，在 HTTP 头中携带 Authorization: Bearer <JWT>。
  5. API 网关或微服务验证 JWT 签名，提取用户身份与权限信息。
  6. 服务根据 JWT 中的声明执行授权决策，返回资源或拒绝请求。
# 典型 JWT 请求示例
GET /api/v1/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
最佳实践：JWT 应设置合理的过期时间（通常 15 分钟～1 小时），并配合刷新令牌（Refresh Token）实现长期会话管理，避免令牌泄露带来的安全风险。
← 上一章 📖 返回目录 下一章 →