JWT 令牌完整解析｜AI 前后端分离、微服务身份认证实战指南

腾势第九

导语

       现在 AI 网页聊天、RAG 知识库 SaaS 平台、大模型 API 网关大量采用前后端分离、微服务架构，传统 Session 会话方案在多服务、多端（网页、小程序、客户端）场景下遇到分布式会话同步难题。JWT（JSON Web Token）作为主流无状态身份令牌方案被广泛使用，但很多开发者只知道它适合分布式，却忽略它原生无法主动吊销令牌、payload 只是编码并非加密等安全坑点。本期拆解 JWT 结构、完整登录流程，对比 JWT 与 Session 差异，详解 Access‑Token+Refresh‑Token 双令牌生产方案，结合 AI 业务梳理常见误区、安全风险与落地最佳实践。

一、什么是 JWT

通俗类比：Session 相当于在服务端前台保存登记本，用户只拿一张取号小票（Session‑ID）；JWT 相当于一张自带完整防伪信息的通行证。登录校验通过之后，服务器把用户身份、权限、过期时间打包，加上防伪签名，整体交给客户端保存。后续每次请求带上这张通行证，服务端只校验签名和有效期，不需要去后端数据库 / Redis 查询会话记录。

JWT 全称 JSON Web Token，RFC‑7519 标准，一种自包含的身份令牌。

⚠️重要：JWT 的 Header、Payload 只是Base64‑URL 编码，不是加密，任何人拿到令牌都可以解码看到里面内容；签名只能防篡改，不能保密数据。

JWT 字符串由三段用.分隔：Header.Payload.Signature

• Header 头部：记录令牌类型、签名算法，例如 HS256；
• Payload 载荷（声明 Claims）：存放业务信息，用户 ID、角色、签发时间iat、过期时间exp；禁止存放密码、身份证等敏感隐私数据；
• Signature 签名：防伪指纹，服务器使用密钥对前两段计算签名。服务端收到 JWT 之后，重新计算签名比对，判断令牌有没有被篡改。
  

关键点：攻击者即便修改 Payload 里的角色，没有服务器密钥，无法生成合法 Signature，校验直接失败。

二、完整 JWT 登录交互流程

• 用户提交账号密码登录请求；
• 后端校验账号密码合法性；
• 校验通过，生成 JWT 令牌，写入用户 ID、角色、过期时间；
• 将 JWT 返回给前端；
• 前端存储令牌；接口请求时，在 HTTP 请求头Authorization: Bearer <token>携带令牌；
• 服务端接收请求，校验签名、校验过期时间；校验通过解析出用户身份执行业务逻辑。
  

对比传统 Session：Session：用户凭证（Session‑ID）存 Cookie；真实身份数据保存在服务端 Redis / 内存。JWT：身份相关声明全部打包在令牌交给客户端，服务端默认不存储会话数据，实现 “无状态”。

三、JWT 与 Session 核心对比

对比维度	JWT 令牌	Session 会话 (Redis)
数据存放	用户身份信息放在客户端令牌	用户会话数据保存在服务端 Redis
分布式扩容	多台服务共享密钥即可校验，无需同步会话数据	需要 Redis 做会话共享，增加中间件依赖
主动失效 / 踢下线	原生很难立刻失效，需要黑名单 / Refresh‑Token 机制	服务端直接删除 Session，可立即强制下线
跨端 & 前后端分离	适配网页、APP、小程序，Header 携带令牌，不受 Cookie 跨域限制	依赖浏览器 Cookie，APP、跨域场景处理复杂
Payload 安全性	Base64 编码可解码，不能存放敏感信息	敏感信息全部存服务端，客户端只有 ID
适用场景	微服务网关、对外开放 API、多端客户端	管理后台、需要频繁强制下线的系统

现实工程不是二选一，很多 AI 系统混合使用两种方案。

四、生产环境标准方案：Access‑Token + Refresh‑Token 双令牌

原生 JWT 最大痛点：令牌一旦签发，在 exp 过期之前默认一直有效。账号封禁、密码修改、令牌泄露，服务端无法立刻让令牌作废。业界成熟解决方案采用双令牌模式：

• Access‑Token（访问令牌）：有效期很短，10‑30 分钟；每次调用 AI 问答、知识库接口使用；泄露之后攻击窗口期很短。
• Refresh‑Token（刷新令牌）：有效期 7‑14 天，存放在服务端 Redis；Access‑Token 过期，用 Refresh‑Token 去接口换取新的 Access‑Token；用户退出登录、封禁账号时，直接删除服务端保存的 Refresh‑Token，实现强制失效。
  

完整流程

• 登录成功返回 Access‑Token、Refresh‑Token；Refresh‑Token 后端存入 Redis；
• 业务请求携带 Access‑Token 访问接口；
• Access‑Token 过期，前端调用刷新接口，提交 Refresh‑Token；
• 后端校验 Refresh‑Token 合法性，生成全新 Access‑Token 返回；
• 用户退出登录：删除 Redis 中 Refresh‑Token，旧令牌彻底失效。
  

高安全系统开启 Refresh‑Token 轮换：每次刷新颁发新 Refresh‑Token，旧的直接作废，降低泄露风险。

五、JWT 存储的两种方案与安全风险

方案 1：LocalStorage/SessionStorage 存放 Access‑Token

✅优点：JS 读取方便，不受 Cookie 跨域限制；❌致命风险：XSS 脚本攻击可以直接读取本地存储窃取令牌，AI 网页项目谨慎使用。
方案 2：HttpOnly Cookie 存放 Refresh‑Token

设置HttpOnly;Secure;SameSite=Lax；JS 脚本无法读取 Cookie，抵御 XSS 窃取令牌；⚠️代价：需要做好 CSRF 跨站请求伪造防护。

生产最佳实践：Refresh‑Token 放入 HttpOnly Cookie；Access‑Token 短期，内存使用，不持久化本地存储。

六、AI 项目典型使用场景

• AI SaaS 网页 RAG 平台：前后端分离，前端 Vue/React，后端 FastAPI；网关层校验 JWT，鉴权之后再转发给 vLLM 推理服务；
• 移动端 AI APP：APP 不支持 Cookie，请求头 Bearer 携带 JWT 访问 API；
• 微服务架构：网关统一解析 JWT，把解析后的用户 ID 透传给下游知识库、推理服务，各个子服务不用重复登录校验；
• 第三方开放 API：对外提供大模型调用接口，客户端携带 JWT 鉴权。
  

注意：AI 管理后台，需要管理员可以强制用户下线，只用原生 JWT 不够，必须搭配 Refresh‑Token 或 Redis 黑名单。

七、线上高频踩坑与认知误区

误区 1 JWT 是加密，Payload 里面可以放密码、身份证

纠正：Payload 只是 Base64‑URL 编码，网上在线工具可以直接解码查看；敏感信息一定放后端数据库，不要写进 JWT 载荷。
误区 2 JWT 无状态 = 完全不需要服务端存储

纠正：想要实现踢用户下线、封禁账号，Refresh‑Token、黑名单依旧需要 Redis 存储，只是不再存储每一个业务会话数据。
误区 3 签发 JWT 之后，随时可以作废令牌

纠正：原生 JWT 依靠过期时间，没有服务端记录就无法立刻失效，必须借助黑名单或者 Refresh‑Token 机制。
误区 4 只要用 JWT 就比 Session 更高级

纠正：技术没有优劣；管理后台、需要频繁强制下线场景，Redis‑Session 更加简单可控；微服务、多端开放 API 更适合 JWT。
误区 5 密钥写死在前端代码

纠正：签名密钥只保存在后端服务器，绝对不能下发前端。
八、生产环境安全检查清单

• 禁止 Payload 存放密码、手机号等敏感个人信息；
• Access‑Token 有效期控制 10‑30 分钟，不要设置几天；
• Refresh‑Token 存入 Redis，退出登录直接删除，实现强制下线；
• 签名密钥使用环境变量注入，不要硬编码在代码仓库；禁用none空签名算法；
• HTTPS 全链路传输令牌，禁止 HTTP 明文传输；
• 优先 HttpOnly Cookie 存放 Refresh‑Token，规避 XSS 窃取；
• 敏感业务系统可以增加 Redis JTI 黑名单作为兜底安全防护。
  

九、本期全文总结

1 JWT 是自包含签名令牌，Header、Payload 仅 Base64 编码不是加密，Signature 用于防篡改，不能保密载荷数据。2 JWT 适合前后端分离、微服务、APP 小程序多端；原生无法主动吊销令牌，生产务必使用 Access‑Token+Refresh‑Token 双令牌方案。3 Session 把身份保存在服务端，方便立刻踢下线；分布式部署需要 Redis 会话共享。4 选型：对外开放 API、多端客户端优先 JWT；管理后台、需要频繁强制下线，Redis‑Session 更简单。也可以两种技术组合使用。5 安全重点：密钥后端保管、短有效期 Access‑Token、Refresh‑Token 后端持久存储、HTTPS 传输、谨慎选择前端存储位置。