Python
【JWT】JWT（JSON Web Token）结构化知识体系（完整版）
文章目录 JWT（JSON Web Token） 一、基础认知层：定义与核心边界 1\. 核心定义 2\. 诞生背景 3\. 适用与不适用场景 二、核心结构层：JWT的标准格式与字段规范 1\. Header（头部） 2\. Payload（载荷） 3\. Signature（签名） 三、核心原理与标准工作流程 1\. 核心底层原理 2\. 标准全流程（前后端分离核心场景） 四、算法体系与分类规范…
文章目录 JWT（JSON Web Token） 一、基础认知层：定义与核心边界 1\. 核心定义 2\. 诞生背景 3\. 适用与不适用场景 二、核心结构层：JWT的标准格式与字段规范 1\. Header（头部） 2\. Payload（载荷） 3\. Signature（签名） 三、核心原理与标准工作流程 1\. 核心底层原理 2\. 标准全流程（前后端分离核心场景） 四、算法体系与分类规范…
本文基于RFC 7519国际标准，从基础认知、核心结构、原理流程、算法体系、特性优劣、安全合规、工程实战、避坑指南、横向对比、进阶场景10个维度，构建JWT完整的结构化知识体系，覆盖从入门到生产落地的全链路内容。
JWT（JSON Web Token）是RFC 7519定义的开放行业标准，用于在网络环境中以紧凑、自包含、可验证的方式，在多方之间安全传输JSON格式的声明信息。
解决传统Session-Cookie认证机制的核心痛点：
| 核心适用场景 | 不适用场景 |
|---|---|
| 前后端分离架构的身份认证 | 需要频繁撤销令牌、强制全平台登出的场景 |
| 微服务/分布式系统的跨服务认证 | 超大量用户、权限实时动态变更的核心系统 |
| 跨域/跨机构的授权与信息交换 | 需要存储大量敏感信息的场景 |
| 移动端APP/小程序/IoT设备认证 | 需要精准统计在线用户、会话管理的场景 |
标准JWT（JWS）采用三段式.分隔结构，格式为：[Header].[Payload].[Signature]，每一段均采用Base64URL编码（URL安全的Base64，替换+//、去除=填充，非普通Base64）。
JSON对象，描述JWT的元数据，Base64URL编码后为第一段字符串，核心作用是声明令牌类型与签名算法。
| 字段 | 必选 | 含义与规范 |
|---|---|---|
| alg | 是 | 签名/加密算法，如HS256、RS256、ES256，none表示无签名（生产环境绝对禁用） |
| typ | 否 | 令牌类型，固定值JWT |
| kid | 否 | 密钥ID，多密钥场景下用于快速匹配验签密钥 |
| cty | 否 | 内容类型，嵌套JWT时固定为JWT |
示例：
{"alg":"RS256","typ":"JWT","kid":"key-202603"}
JSON对象，存放核心声明（Claims）与业务数据，Base64URL编码后为第二段字符串。
⚠️ 关键警告：Base64URL是编码而非加密，Payload内容任何人拿到令牌均可解码，绝对禁止存放密码、身份证、手机号等敏感信息。
Payload的Claims分为三类：
注册声明（RFC预定义，推荐必用）
| 字段 | 全称 | 核心含义 |
|---|---|---|
| iss | issuer | 令牌签发人 |
| sub | subject | 令牌主题，通常为用户唯一ID |
| aud | audience | 令牌受众，接收方标识 |
| exp | expiration time | 过期时间，Unix时间戳，验签必须强制校验 |
| nbf | not before | 生效时间，该时间前令牌无效 |
| iat | issued at | 签发时间，Unix时间戳 |
| jti | JWT ID | 令牌唯一标识，用于防重放、黑名单管理 |
示例：
{"sub":"user_123456","iss":"auth-center","aud":"business-system","iat":1710000000,"exp":1710009000,"jti":"token_abc123def456","role":"admin","tenant_id":"tenant_789"}
JWT的核心安全屏障，防止Header和Payload被篡改，为第三段字符串。
签名算法( Base64URL(Header) + "." + Base64URL(Payload) , 密钥/私钥 )Authorization字段，标准格式：Authorization: Bearer <JWT令牌>401 Unauthorized/403 Forbidden日常使用的JWT默认是JWS，JWE用于高安全敏感场景，核心对比如下：
| 特性 | JWS（JSON Web Signature） | JWE（JSON Web Encryption） |
|---|---|---|
| 核心目标 | 防内容篡改、身份可验证 | 防篡改+内容加密，保障数据机密性 |
| 结构 | 三段式（Header.Payload.Signature） | 五段式（受保护头.加密密钥.IV.密文.认证标签） |
| 内容可见性 | Payload Base64编码，明文可见 | Payload 对称加密，仅持有私钥方可解密 |
| 性能 | 高，仅签名/验签计算 | 低，需加解密+验签双重计算 |
| 适用场景 | 非敏感信息传递、通用身份认证 | 敏感信息传输、高安全级别的跨机构调用 |
| 普及度 | 极高，行业默认方案 | 较低，仅高安全场景使用 |
分为对称加密、非对称加密两大类，生产环境优先选择非对称算法。
none无签名算法，生产环境绝对禁用，攻击者可任意伪造令牌。
| 风险类型 | 风险详情 | 强制防护方案 |
|---|---|---|
| 令牌篡改攻击 | 攻击者修改Payload权限/用户ID，伪造身份 | 1. 强制校验签名，禁用none算法；2. 验签时强制指定算法，禁止信任Header中的alg字段，防止算法替换攻击；3. 生产环境优先使用非对称算法 |
| 令牌窃取攻击 | XSS攻击窃取客户端令牌、中间人攻击窃取传输中的令牌 | 1. 强制HTTPS传输，禁止HTTP明文；2. 客户端优先使用HttpOnly+Secure+SameSite Cookie存储，禁止localStorage存储；3. 缩短访问令牌有效期；4. 实现IP/User-Agent绑定，异常环境直接拒绝 |
| 不可撤销风险 | 用户登出/权限变更后，原令牌依然有效 | 1. 短有效期+双令牌刷新机制；2. 基于Redis的分布式黑名单系统，按jti作废令牌；3. 令牌版本号机制，用户状态变更时升级版本号，验签时校验；4. 定期密钥轮转 |
| 重放攻击 | 攻击者窃取令牌后重复发起请求 | 1. 强制校验exp/nbf，缩短有效期；2. 用jti记录已使用令牌，防重放；3. 重要接口增加时间戳+nonce随机数校验 |
| 敏感信息泄露 | Payload存放敏感信息被解码泄露 | 1. Payload仅存放必要的非敏感信息；2. 绝对禁止存放密码、身份证等敏感数据；3. 必须传输敏感信息时使用JWE加密方案 |
| 密钥管理风险 | 密钥硬编码、弱密钥、泄露 | 1. 密钥通过KMS/配置中心管理，禁止硬编码；2. 对称密钥长度≥256位，RSA密钥≥2048位（优先4096位）；3. 不同环境密钥完全隔离，定期轮转 |
| 越权攻击 | 攻击者利用伪造的权限字段越权访问 | 1. 核心接口/高敏感操作必须二次校验权限，不单独信任JWT；2. 高风险操作（转账、改密、管理员操作）必须二次身份校验 |
✅ 强制HTTPS传输，全链路加密
✅ 优先使用RS256/ES256非对称算法，避免HS256对称算法
✅ 强制校验签名、exp、nbf、iss、aud核心字段
✅ 绝对禁用none算法，禁用弱加密算法
✅ 访问令牌有效期控制在30分钟内，敏感场景≤15分钟
✅ 客户端令牌存储优先HttpOnly+Secure+SameSite Cookie
✅ 实现分布式黑名单机制，支持令牌主动作废
✅ 密钥通过专业KMS管理，定期轮转，环境隔离
✅ 高敏感操作二次身份校验，不单独依赖JWT
✅ 验签时强制指定算法，防范算法替换攻击
| 编程语言 | 主流实现库 |
|---|---|
| Java | JJWT、Auth0 java-jwt、Spring Security OAuth2 原生集成 |
| Python | PyJWT、python-jose |
| Node.js | jsonwebtoken、jose |
| Go | golang-jwt/jwt |
| PHP | firebase/php-jwt |
| C# | System.IdentityModel.Tokens.Jwt |
解决「短有效期安全要求」与「用户免频繁登录体验」的核心矛盾，是生产环境的标准方案。
| 对比维度 | JWT | Session-Cookie |
|---|---|---|
| 状态存储 | 客户端存储，服务端无状态 | 服务端存储Session，客户端仅存SessionID |
| 分布式适配 | 天然支持，无额外开发 | 需要Session共享，复杂度高 |
| 跨域支持 | 原生支持，无限制 | 受同源策略限制，跨域配置复杂 |
| 多端适配 | 全端完美支持 | 移动端/IoT适配性差 |
| 核心安全风险 | XSS窃取、不可撤销、篡改 | CSRF、Session劫持、固定会话 |
| 服务端压力 | 低，仅验签，无需查库 | 高，每次请求需查询Session存储 |
| 网络开销 | 较高，令牌体积大 | 低，仅SessionID |
| 权限实时性 | 差，需等待令牌过期 | 好，服务端可实时修改 |
| 强制登出 | 需额外黑名单机制 | 原生支持，直接删除Session即可 |
| 方案等级 | 实现方式 | 适用场景 |
|---|---|---|
| 轻量级 | 短Access Token有效期+Refresh Token黑名单，用户登出仅作废Refresh Token，Access Token自然过期 | 中小规模系统、非核心业务、低安全要求场景 |
| 中量级 | Redis分布式黑名单，将需作废的令牌jti存入黑名单，过期时间与令牌exp一致，验签时先查黑名单 | 中大型系统、核心业务、高安全要求场景 |
| 重量级 | 令牌版本号机制，用户表维护token_version，签发时存入Payload，用户状态变更时升级版本号，验签时校验与数据库是否一致 | 超大规模系统、金融/政务等高安全等级场景 |
| 紧急方案 | 密钥轮转，立即更换签名密钥，旧密钥签发的所有令牌全部失效 | 密钥泄露、大规模安全事件等紧急场景 |
tenant_id租户ID字段，网关验签后透传给下游服务，实现多租户数据隔离内网/离线环境下，客户端可本地完成JWT签名校验，无需联网与服务端交互，完美适配IoT设备、离线工业系统、内网应用等场景。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online