【JWT】JWT（JSON Web Token）结构化知识体系（完整版）

优质文章学习记录

— 21 min read
【JWT】JWT（JSON Web Token）结构化知识体系（完整版）

文章目录

JWT（JSON Web Token）

本文基于RFC 7519国际标准，从基础认知、核心结构、原理流程、算法体系、特性优劣、安全合规、工程实战、避坑指南、横向对比、进阶场景10个维度，构建JWT完整的结构化知识体系，覆盖从入门到生产落地的全链路内容。

一、基础认知层：定义与核心边界

1. 核心定义

JWT（JSON Web Token）是RFC 7519定义的开放行业标准，用于在网络环境中以紧凑、自包含、可验证的方式，在多方之间安全传输JSON格式的声明信息。

  • 核心本质：基于JSON的无状态令牌规范，核心特性是自包含与无状态
  • 标准家族：JWT是统称，包含JWS（签名令牌，RFC 7515）和JWE（加密令牌，RFC 7516）两大实现分支，日常所说的JWT默认指JWS

2. 诞生背景

解决传统Session-Cookie认证机制的核心痛点：

  • 分布式系统Session共享复杂度高，水平扩展受限
  • Cookie受同源策略限制，跨域认证实现困难
  • 移动端/小程序/IoT设备对Cookie适配性差
  • 存在CSRF攻击、Session劫持等安全风险

3. 适用与不适用场景

核心适用场景不适用场景
前后端分离架构的身份认证需要频繁撤销令牌、强制全平台登出的场景
微服务/分布式系统的跨服务认证超大量用户、权限实时动态变更的核心系统
跨域/跨机构的授权与信息交换需要存储大量敏感信息的场景
移动端APP/小程序/IoT设备认证需要精准统计在线用户、会话管理的场景

二、核心结构层：JWT的标准格式与字段规范

标准JWT（JWS）采用三段式.分隔结构，格式为：[Header].[Payload].[Signature]，每一段均采用Base64URL编码（URL安全的Base64，替换+//、去除=填充，非普通Base64）。

1. Header（头部）

JSON对象，描述JWT的元数据，Base64URL编码后为第一段字符串，核心作用是声明令牌类型与签名算法。

字段必选含义与规范
alg是签名/加密算法，如HS256、RS256、ES256，none表示无签名（生产环境绝对禁用）
typ否令牌类型，固定值JWT
kid否密钥ID，多密钥场景下用于快速匹配验签密钥
cty否内容类型，嵌套JWT时固定为JWT

示例：

{"alg":"RS256","typ":"JWT","kid":"key-202603"}

2. Payload（载荷）

JSON对象，存放核心声明（Claims）与业务数据，Base64URL编码后为第二段字符串。

⚠️ 关键警告：Base64URL是编码而非加密，Payload内容任何人拿到令牌均可解码，绝对禁止存放密码、身份证、手机号等敏感信息。

Payload的Claims分为三类：

  1. 公共声明：自定义可公开字段，如用户名、角色、租户ID，需避免与注册声明冲突
  2. 私有声明：通信双方约定的非公开业务字段，仅用于内部业务逻辑

注册声明（RFC预定义，推荐必用）

字段全称核心含义
ississuer令牌签发人
subsubject令牌主题，通常为用户唯一ID
audaudience令牌受众，接收方标识
expexpiration time过期时间，Unix时间戳，验签必须强制校验
nbfnot before生效时间，该时间前令牌无效
iatissued at签发时间，Unix时间戳
jtiJWT ID令牌唯一标识，用于防重放、黑名单管理

示例：

{"sub":"user_123456","iss":"auth-center","aud":"business-system","iat":1710000000,"exp":1710009000,"jti":"token_abc123def456","role":"admin","tenant_id":"tenant_789"}

3. Signature（签名）

JWT的核心安全屏障，防止Header和Payload被篡改，为第三段字符串。

  • 生成规则：签名算法( Base64URL(Header) + "." + Base64URL(Payload) , 密钥/私钥 )
  • 验签逻辑：服务端用相同算法和对应密钥（公钥，非对称算法）重新计算签名，与令牌中的签名对比，一致则证明内容未被篡改
  • 核心边界：签名仅防篡改，不防内容泄露，Payload依然是明文编码状态

三、核心原理与标准工作流程

1. 核心底层原理

  1. 无状态认证：服务端不存储任何会话信息，所有用户身份/权限状态均封装在令牌中，仅需验签即可完成认证，彻底解决分布式Session共享问题
  2. 不可篡改性：基于成熟密码学算法，Header/Payload任何字节的修改都会导致签名失效，从根本上防止身份伪造
  3. 自包含性：令牌本身包含认证与业务所需的全部信息，验签通过后无需额外查询数据库，大幅降低服务端IO压力

2. 标准全流程（前后端分离核心场景）

  1. 用户提交账号密码等凭证，发起登录请求
  2. 服务端校验凭证合法性，提取用户核心信息，生成并签发JWT令牌（设置过期时间、核心声明）
  3. 服务端将JWT返回给客户端
  4. 客户端存储JWT（推荐HttpOnly+Secure+SameSite Cookie，禁止localStorage/sessionStorage）
  5. 客户端后续请求，将JWT放入HTTP请求头Authorization字段，标准格式：Authorization: Bearer <JWT令牌>
  6. 服务端/网关接收请求，提取JWT并执行全量校验：
    • 格式合法性校验（三段式、编码合规）
    • 签名有效性校验（防篡改）
    • 声明校验（exp/nbf有效期、iss签发人、aud受众合规性）
    • 黑名单校验（是否已被主动作废）
  7. 校验全量通过，识别用户身份，执行业务逻辑并返回结果
  8. 任意一项校验失败，直接返回401 Unauthorized/403 Forbidden

四、算法体系与分类规范

1. JWT两大分支：JWS vs JWE

日常使用的JWT默认是JWS，JWE用于高安全敏感场景，核心对比如下：

特性JWS（JSON Web Signature）JWE（JSON Web Encryption）
核心目标防内容篡改、身份可验证防篡改+内容加密，保障数据机密性
结构三段式（Header.Payload.Signature）五段式（受保护头.加密密钥.IV.密文.认证标签）
内容可见性Payload Base64编码，明文可见Payload 对称加密，仅持有私钥方可解密
性能高，仅签名/验签计算低，需加解密+验签双重计算
适用场景非敏感信息传递、通用身份认证敏感信息传输、高安全级别的跨机构调用
普及度极高，行业默认方案较低，仅高安全场景使用

2. JWS核心签名算法

分为对称加密、非对称加密两大类，生产环境优先选择非对称算法。

（1）对称加密算法（HS系列）
  • 代表算法：HS256（HMAC-SHA256）、HS384、HS512
  • 核心逻辑：使用同一个密钥完成签名和验签
  • 优势：计算速度快、性能高、实现简单
  • 劣势：密钥分发风险高，所有验签服务必须持有同一密钥，密钥泄露可导致全体系伪造；不支持不可否认
  • 适用场景：单体应用、内部可信服务集群、单节点验签
（2）非对称加密算法（RS/ES/PS系列）
  • 主流算法：
    • RS256（RSA-SHA256）：行业通用RSA算法，兼容性最强
    • ES256（ECDSA-SHA256）：椭圆曲线算法，同安全强度下密钥更短、性能更高
    • PS256（RSA-PSS-SHA256）：RSA增强填充模式，安全性更高
  • 核心逻辑：私钥签名，公钥验签；公钥可公开分发，私钥仅签发方持有
  • 优势：密钥安全性高，公钥泄露无风险；支持不可否认；完美适配多服务/跨机构场景
  • 劣势：计算性能低于HS系列，密钥管理复杂度更高
  • 适用场景：微服务分布式系统、跨域跨机构认证、第三方开放平台、高安全要求业务
（3）禁用算法

none无签名算法，生产环境绝对禁用，攻击者可任意伪造令牌。

五、核心特性与优劣势分析

1. 核心优势

  1. 天然分布式适配：彻底无状态，服务端无需存储会话，无需Session共享，水平扩展零成本，完美适配云原生微服务架构
  2. 原生跨域支持：不受Cookie同源策略限制，可在多域名、多服务、多端之间自由传递，跨域认证实现极简
  3. 全场景多端适配：完美支持PC Web、移动端APP、小程序、IoT设备，不受Cookie禁用限制
  4. 低服务端压力：自包含特性，验签通过后无需重复查询数据库，大幅减少数据库IO开销
  5. 高标准化兼容性：基于RFC国际标准，所有主流编程语言、框架均有成熟实现库，跨语言跨平台兼容性极强
  6. CSRF攻击天然免疫：不依赖Cookie，从根源上规避基于Cookie的CSRF攻击风险
  7. 安全可控性强：基于成熟密码学体系，可灵活选择算法，配合安全策略可满足绝大多数业务的安全要求

2. 核心劣势与天生缺陷

  1. 令牌不可撤销（最大痛点）：一旦签发，过期前始终有效，服务端无法主动作废，即使用户登出、密码修改、权限回收，原令牌依然可用
  2. 明文内容泄露风险：Payload仅做Base64编码，无加密能力，无法存储敏感信息
  3. 网络开销较大：令牌长度远大于SessionID，Payload字段越多体积越大，每次请求均需携带，增加网络传输开销
  4. 权限状态无法实时同步：用户权限、身份信息变更后，必须等待令牌过期或重新登录才能生效，无法实时更新
  5. 密钥泄露致命风险：对称算法密钥泄露可导致任意令牌伪造；非对称算法私钥泄露可导致整个认证体系完全崩溃
  6. 重放攻击风险：令牌一旦被窃取，攻击者可在有效期内无限次使用，原生无防重放能力
  7. 会话管理能力缺失：服务端无会话存储，无法精准统计在线用户，无法原生实现全平台强制登出

六、安全合规体系：生产环境必守规范

1. 核心安全风险与防护方案

风险类型风险详情强制防护方案
令牌篡改攻击攻击者修改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. 高风险操作（转账、改密、管理员操作）必须二次身份校验

2. 生产环境安全必做清单

✅ 强制HTTPS传输，全链路加密
✅ 优先使用RS256/ES256非对称算法，避免HS256对称算法
✅ 强制校验签名、exp、nbf、iss、aud核心字段
✅ 绝对禁用none算法，禁用弱加密算法
✅ 访问令牌有效期控制在30分钟内，敏感场景≤15分钟
✅ 客户端令牌存储优先HttpOnly+Secure+SameSite Cookie
✅ 实现分布式黑名单机制，支持令牌主动作废
✅ 密钥通过专业KMS管理，定期轮转，环境隔离
✅ 高敏感操作二次身份校验，不单独依赖JWT
✅ 验签时强制指定算法，防范算法替换攻击

七、工程化实战：落地最佳实践

1. 主流语言成熟实现库

编程语言主流实现库
JavaJJWT、Auth0 java-jwt、Spring Security OAuth2 原生集成
PythonPyJWT、python-jose
Node.jsjsonwebtoken、jose
Gogolang-jwt/jwt
PHPfirebase/php-jwt
C#System.IdentityModel.Tokens.Jwt

2. 核心工程化方案：双令牌无感刷新机制

解决「短有效期安全要求」与「用户免频繁登录体验」的核心矛盾，是生产环境的标准方案。

核心设计
  • Access Token（访问令牌）：有效期15-30分钟，用于普通接口请求认证，每次请求携带，泄露风险低
  • Refresh Token（刷新令牌）：有效期7-30天，仅用于刷新Access Token，不用于普通接口请求，需服务端存储并绑定用户
完整流程
  1. 用户登录成功，服务端同时签发Access Token和Refresh Token，Refresh Token存入数据库/Redis
  2. 前端携带Access Token发起请求，过期后服务端返回401
  3. 前端拦截401响应，携带Refresh Token调用专用刷新接口
  4. 服务端校验Refresh Token的合法性、是否在黑名单、是否绑定对应用户
  5. 校验通过，签发新的Access Token，可选同步刷新Refresh Token（滑动有效期）
  6. 前端用新的Access Token重新发起原请求，用户完全无感知
  7. 校验失败，直接清空令牌，强制用户重新登录
安全补充
  • Refresh Token必须加密存储，每次刷新可轮换，降低泄露风险
  • 用户登出、密码修改、权限回收时，将Refresh Token和对应Access Token的jti同步加入黑名单

3. 分布式系统落地架构

  • 网关层统一验签：API网关（Spring Cloud Gateway、Kong、APISIX）统一拦截所有请求，完成JWT全量校验，验签通过后将用户信息透传给下游微服务
  • 下游服务免重复验签：直接信任网关透传的用户信息，大幅提升集群性能
  • 统一密钥管理：签发服务单独持有私钥，网关/下游服务仅分发公钥，杜绝私钥泄露风险
  • 分布式黑名单：基于Redis集群实现，全节点共享，保证作废令牌全网即时生效

八、常见误区与避坑指南

  1. 误区1：JWT的Payload是加密的，可以放敏感信息
    • 纠正：Base64URL是编码而非加密，任何人都可解码，Payload是明文状态，绝对禁止存放敏感信息
  2. 误区2：JWT比Session-Cookie更安全
    • 纠正：无绝对的安全性高低，两者有不同的安全风险，核心在于正确的安全配置，而非技术本身
  3. 误区3：JWT可以完全替代Session
    • 纠正：两者是互补而非替代关系，JWT适合分布式、跨域、多端场景；Session适合需要实时权限控制、强制登出、会话管理的场景
  4. 误区4：验签通过就可以完全信任Payload内容
    • 纠正：高敏感操作必须二次校验权限和用户状态，防止令牌窃取后被滥用
  5. 误区5：JWT有效期越长越好，用户体验更好
    • 纠正：有效期越长，安全风险越高，必须用「短访问令牌+长刷新令牌」平衡安全与体验
  6. 误区6：HS256和RS256安全性一致
    • 纠正：HS256是对称算法，密钥必须严格保密；RS256是非对称算法，公钥可公开，安全性和适用场景完全不同，存在算法替换攻击风险
  7. 误区7：JWT必须放在Authorization请求头中
    • 纠正：这是标准Bearer方案，推荐使用；但防XSS场景下，优先放在HttpOnly Cookie中，安全性更高

九、横向对比与边界认知

对比维度JWTSession-Cookie
状态存储客户端存储，服务端无状态服务端存储Session，客户端仅存SessionID
分布式适配天然支持，无额外开发需要Session共享，复杂度高
跨域支持原生支持，无限制受同源策略限制，跨域配置复杂
多端适配全端完美支持移动端/IoT适配性差
核心安全风险XSS窃取、不可撤销、篡改CSRF、Session劫持、固定会话
服务端压力低，仅验签，无需查库高，每次请求需查询Session存储
网络开销较高，令牌体积大低，仅SessionID
权限实时性差，需等待令牌过期好，服务端可实时修改
强制登出需额外黑名单机制原生支持，直接删除Session即可

2. JWT与OAuth2.0的关系

  • 本质区别：两者不是同一层面的概念
    • JWT：令牌的格式规范，是一种令牌的实现形式
    • OAuth2.0：授权协议框架，定义了授权的流程、角色与模式
  • 关联关系：OAuth2.0的授权码、密码等模式，最终签发的Access Token，可以用JWT格式实现；JWT是OAuth2.0的主流令牌实现方案，两者是互补关系，而非对等关系

3. JWT与SSO单点登录的关系

  • SSO核心目标：一次登录，多系统/多域名访问
  • JWT是SSO的优秀实现方案：用户在统一认证中心登录后签发JWT，多个业务系统共享验签公钥，无需与认证中心重复交互，即可完成身份校验，极简实现跨域、跨系统的单点登录
  • 优势：相比CAS等传统SSO方案，JWT实现的SSO无需多次重定向，性能更高，多端适配性更强

十、进阶场景与解决方案

1. 令牌撤销与强制登出的分级方案

方案等级实现方式适用场景
轻量级短Access Token有效期+Refresh Token黑名单，用户登出仅作废Refresh Token，Access Token自然过期中小规模系统、非核心业务、低安全要求场景
中量级Redis分布式黑名单，将需作废的令牌jti存入黑名单，过期时间与令牌exp一致，验签时先查黑名单中大型系统、核心业务、高安全要求场景
重量级令牌版本号机制，用户表维护token_version，签发时存入Payload，用户状态变更时升级版本号，验签时校验与数据库是否一致超大规模系统、金融/政务等高安全等级场景
紧急方案密钥轮转，立即更换签名密钥，旧密钥签发的所有令牌全部失效密钥泄露、大规模安全事件等紧急场景

2. 细粒度权限控制方案

  1. 极简方案：JWT仅存放用户ID/角色ID，服务端/网关二次查询细粒度权限，保证权限实时性
  2. 平衡方案：JWT存放权限哈希，服务端校验哈希与当前用户权限哈希是否一致，不一致则拒绝，平衡性能与实时性
  3. 分布式方案：网关层集成统一权限中心，完成接口权限的统一校验，下游服务无需处理权限逻辑

3. 多租户场景适配

  • 基础方案：Payload中增加tenant_id租户ID字段，网关验签后透传给下游服务，实现多租户数据隔离
  • 高安全方案：不同租户使用独立的签名密钥，进一步提升租户隔离性与安全性

4. 离线认证场景

内网/离线环境下，客户端可本地完成JWT签名校验，无需联网与服务端交互，完美适配IoT设备、离线工业系统、内网应用等场景。

核心使用原则总结

  1. 扬长避短：充分发挥JWT无状态、跨域、多端适配的优势，通过配套机制规避不可撤销、明文泄露的天生缺陷
  2. 安全优先：永远将安全放在第一位，短有效期、非对称算法、HTTPS、HttpOnly存储、黑名单机制为核心安全底线
  3. 场景适配：不盲目跟风使用JWT，根据业务场景选择技术方案，需要实时权限控制、强会话管理的场景需搭配额外机制，或选择Session方案
  4. 最小权限原则：Payload仅存放必要的非敏感信息，字段越少越好，降低泄露风险与令牌体积

Read more

VsCode 远程 Copilot 调用 Claude Agent 提示 “无效请求”？参数配置错误的修正

解决 VsCode 远程 Copilot 调用 Claude Agent 提示“无效请求”问题 当在 VsCode 中通过远程 Copilot 调用 Claude Agent 时，若出现“无效请求”错误提示，通常与参数配置错误有关。以下方法可帮助排查和修正问题。 检查 API 密钥配置 确保 Claude Agent 的 API 密钥已正确配置在 VsCode 设置中。打开 VsCode 的设置文件（settings.json），验证以下参数是否完整： "claude.apiKey": "your_api_key_here"
【薅羊毛教程】LLaMaFactory 不用本地跑！免费 GPU，一键微调大模型

【薅羊毛教程】LLaMaFactory 不用本地跑！免费 GPU，一键微调大模型

一、环境 之前介绍过本地部署LLaMaFactory微调平台（https://blog.ZEEKLOG.net/m0_73982863/article/details/159208213?spm=1001.2014.3001.5501），如果你还在为设备问题而烦恼，那就来薅羊毛吧（手动狗头）。 首先注册魔搭社区，绑定个人阿里云账号即可，详情见：https://www.modelscope.cn/my/mynotebook ；然后就可免费获得36小时GPU环境。 8核：CPU有8个核心，主要负责数据的调度和预处理；32GB：内存，数据从硬盘加载后会暂时存放这里；显存24G；（比我自己的老古董好多 T-T） Ubuntu 22.04：Linux操作系统； CUDA 12.8.1：英伟达的并行计算平台。12.8版本意味着它支持最新的RTX

Qwen-Image-Edit-2511与Stable Diffusion对比，谁更适合编辑？

Qwen-Image-Edit-2511与Stable Diffusion对比，谁更适合编辑？ 图像编辑正从“修图工具”走向“语义级视觉重构”，而选择一款真正适合编辑任务的模型，远比选生成模型更考验工程直觉。Qwen-Image-Edit-2511 和 Stable Diffusion（尤其是 SDXL Turbo、SDXL Refiner 及其编辑插件如 Inpaint Anything、ControlNet+Inpainting 工作流）常被拿来比较——但它们本质不同：一个是原生为编辑而生的端到端架构，另一个是以生成为核心、靠插件和提示工程“改造”出编辑能力的通用扩散模型。 本文不谈参数、不列FID分数，而是聚焦一个最朴素的问题：当你手头有一张产品图、一张人像、一张工业设计稿，需要精准替换背景、保持人物不变地换装、给机械结构添加透视线、或让多人合影在风格迁移后仍不“串脸”——哪款工具能让你少调参、少试错、少返工？我们用真实编辑任务说话。 1. 设计哲学差异：编辑即目的，还是生成的副产品？

GitHub Copilot 教程

文章来源：https://vscode.it-docs.cn/docs/copilot/overview.html GitHub Copilot 为 Visual Studio Code 增加了多代理开发功能。规划好你的方法，然后让AI代理在项目中实现并验证代码变更。并行运行多个代理会话：本地、后台或云端。从一个中心视角管理所有角色。内联建议、内联聊天和智能行为会帮助你完成整个编码流程。 代理与代理会话 代理端到端地处理完整的编码任务。给代理一个高级任务，它会将工作拆分成步骤，编辑文件，运行终端命令，调用工具，并在遇到错误或测试失败时自我纠正。每个任务都运行在一个代理会话中，这是一个持续存在的对话，你可以跟踪、暂停、继续或交接给另一个代理。 重要 你们组织可能在VS Code中禁用了代理。请联系你的管理员以启用此功能。 从中央视图管理会话 并行运行多个代理会话，每个会话专注于不同的任务。聊天面板中的会话视图为你提供了一个统一的地方来监控所有活跃会话，无论是本地运行、后台还是云端运行。查看每次会话的状态，切换，查看文件变更，