API 接口安全：用 JWT + Refresh Token 解决 Token 过期与身份伪造问题
在分布式系统与前后端分离架构中，API 接口是数据交互的核心通道，其安全直接决定了系统的信任边界。传统 Token 认证方案常陷入 "两难困境"：若 Token 有效期过长，一旦泄露易引发身份伪造风险；若有效期过短，又会频繁触发用户重新登录，严重影响体验。而 JWT（JSON Web Token）与 Refresh Token 的组合方案，恰好能在 "安全" 与 "体验" 之间找到平衡点，既解决身份伪造问题，又优化 Token 过期后的处理流程。
一、先搞懂：JWT 如何防身份伪造？
JWT 是一种基于 JSON 的轻量级认证令牌，核心价值在于 "可验证性" 与 "自包含性"------ 无需服务端存储令牌信息，只需通过预设规则即可验证令牌是否被篡改，从根源上降低身份伪造风险。
1. JWT 的结构：3 部分组成的 "安全凭证"
JWT 由 Header（头部）、Payload（载荷）、Signature（签名） 三部分构成，各部分用 "." 分隔，例如：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsIm5hbWUiOiJKb2huIiwiZXhwIjoxNzE3MjQwODAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c。
- Header（头部）：声明令牌类型（typ）与签名算法（alg），例如指定用 HS256（HMAC SHA256）加密。这部分会通过 Base64 编码（非加密，仅编码），确保传输格式统一。
- Payload（载荷）：存储 "非敏感" 的用户身份信息（如用户 ID、角色、令牌过期时间 exp），同样通过 Base64 编码。需注意：Payload 不是加密字段，解码后可直接查看，因此绝不能存放密码、手机号等敏感数据。
- Signature（签名）：JWT 防伪造的核心。服务端会用 Header 中声明的算法，将 "编码后的 Header + 编码后的 Payload + 服务端密钥" 三者组合加密，生成签名。
2. 防伪造原理：签名验证锁死 "篡改路径"
当客户端携带 JWT 访问 API 时，服务端会执行以下验证流程，确保令牌未被伪造：
- 服务端从 JWT 中提取 Header 和 Payload，并用相同的 Base64 编码方式处理；
- 使用 Header 中声明的算法（如 HS256），结合服务端私有密钥，重新计算签名；
- 将重新计算的签名与 JWT 中的 Signature 对比：若一致，说明令牌未被篡改；若不一致，直接判定为无效令牌，拒绝接口请求。
由于服务端密钥仅保存在服务端，外部无法获取，即便攻击者篡改了 Payload 中的用户 ID（如将普通用户改为管理员），也无法生成匹配的签名，从而彻底阻断身份伪造的可能。
二、再解决：Refresh Token 如何优化 Token 过期问题？
JWT 的优势是防伪造，但它仍有 "短板"：若为了安全将 JWT 有效期设得很短（如 15 分钟），用户在使用过程中会频繁遇到 "令牌过期"，需重新输入账号密码登录，体验极差。而 Refresh Token（刷新令牌） 的出现，就是为了在不降低安全的前提下，解决 "频繁登录" 问题。
1. Refresh Token 的核心特性
- 长效性：有效期远长于 JWT（如 7 天、30 天），可理解为 "用户身份的'长期凭证'"；
- 专用性：仅用于向 "令牌刷新接口" 请求新的 JWT，不能直接访问业务 API；
- 安全性：需存储在客户端的安全位置（如 HttpOnly Cookie），避免被前端脚本窃取。
2. 与 JWT 的关键差异
| 对比维度 | JWT | Refresh Token |
|---|---|---|
| 有效期 | 短期（15-60 分钟） | 长期（7-30 天） |
| 主要用途 | 访问业务 API | 获取新的 JWT |
| 存储位置 | 前端内存（如 Vuex） | HttpOnly Cookie |
| 安全级别 | 中（短期降低泄露风险） | 高（专用接口 + 安全存储） |
三、核心方案：JWT + Refresh Token 工作流程
两者结合的核心逻辑是：用 JWT 保障业务接口的实时安全 ，用 Refresh Token 保障 "JWT 过期后无需重新登录"，完整流程可分为 4 步：
步骤 1：用户首次登录，获取双令牌
- 客户端（如手机 App、网页）向服务端 "登录接口" 提交身份凭证（如账号密码、验证码）；
- 服务端验证凭证通过后，生成两组令牌：
- JWT：设置短期有效期（如 30 分钟），包含用户 ID、角色等非敏感信息；
- Refresh Token：设置长期有效期（如 7 天），生成随机字符串（无需包含用户信息）；
- 服务端将 JWT 直接返回给客户端（如放在响应体中），将 Refresh Token 存入 HttpOnly Cookie（无法被前端 JavaScript 访问），一同返回给客户端。
步骤 2：日常接口请求，用 JWT 认证
- 客户端每次访问业务 API 时，将 JWT 放入请求头的
Authorization字段（格式：Bearer <JWT>）； - 服务端接口收到请求后，先提取 JWT 并验证：
- 验证签名是否正确（防篡改）；
- 验证
exp字段（是否过期）； - 验证
iss（签发者）、aud（受众）等字段（确保令牌来源合法）；
- 验证通过则处理接口逻辑，返回数据；验证失败（如签名错误、已过期）则返回 401 错误。
步骤 3：JWT 过期，用 Refresh Token 刷新
- 当服务端返回 "JWT 过期" 的 401 错误时，客户端自动向服务端 "令牌刷新接口" 发起请求；
- 客户端无需手动处理，因为 Refresh Token 已存在 HttpOnly Cookie 中，会自动随请求发送到服务端；
- 服务端验证 Refresh Token：
- 检查 Refresh Token 是否存在于服务端存储（如 Redis、数据库）中；
- 检查 Refresh Token 是否过期；
- 检查 Refresh Token 是否被标记为 "已吊销"（如用户登出、账号异常）；
- 验证通过后，服务端生成新的 JWT（有效期重置），返回给客户端；Refresh Token 可选择 "续期"（延长有效期）或 "保持不变"（视业务需求而定）。
步骤 4：Refresh Token 过期，引导重新登录
- 若 Refresh Token 过期或验证失败（如被吊销），服务端返回 "刷新令牌无效" 的 401 错误；
- 客户端收到该错误后，无法再获取新的 JWT，需引导用户跳转到登录页，重新输入凭证登录。
四、必须注意的 4 个安全实践
JWT + Refresh Token 方案的安全性，依赖于 "正确的实现细节"，以下 4 点实践缺一不可：
1. Refresh Token 必须用 HttpOnly Cookie 存储
- 禁止将 Refresh Token 存在 localStorage 或 sessionStorage 中 ------ 这些存储方式可被前端脚本访问，若页面存在 XSS（跨站脚本攻击）漏洞，Refresh Token 会被窃取；
- 用 HttpOnly Cookie 存储时，还需开启
Secure选项（仅通过 HTTPS 传输）和SameSite选项（限制跨域请求携带），进一步降低泄露风险。
2. 服务端需管理 Refresh Token 的状态
- 不要将 Refresh Token 设计为 "无状态"------ 需在服务端存储 Refresh Token 的状态（如存入 Redis，Key 为 Refresh Token，Value 为用户 ID + 过期时间）；
- 当用户主动登出、修改密码或账号被冻结时，需立即从服务端删除对应的 Refresh Token（即 "吊销"），避免被非法使用。
3. JWT 签名密钥需严格管理
- 密钥（如 HS256 算法的密钥、RS256 算法的私钥）绝不能硬编码在代码中，也不能暴露到前端；
- 需用环境变量（如 Docker 环境变量、K8s ConfigMap）存储密钥，并定期轮换（如每 3 个月更新一次），降低密钥泄露后的风险。
4. 强制所有接口使用 HTTPS
- JWT 和 Refresh Token 在传输过程中，若被中间人窃取，仍可能引发安全问题；
- 必须强制所有 API 接口（包括登录、刷新令牌接口）使用 HTTPS，通过 TLS 加密传输数据，防止令牌被拦截。
五、常见误区：别让 "细节" 毁了安全
- 误区 1：认为 JWT 的 Payload 是加密的。实际上，Payload 仅通过 Base64 编码，任何人都可解码查看，因此绝不能存放敏感信息；
- 误区 2 ：不对 JWT 做 "过期验证"。即便 JWT 短期有效，服务端仍需严格检查
exp字段，避免攻击者利用过期 JWT 发起请求； - 误区 3：Refresh Token 不设有效期。长期有效的 Refresh Token 若泄露，风险极高，建议设置合理有效期（如 7-30 天），并在用户长期未使用时自动失效。
总结
JWT + Refresh Token 方案，通过 "短期 JWT 防伪造、长期 Refresh Token 免登录" 的组合，完美解决了传统 Token 认证的 "安全与体验" 矛盾。该方案无需服务端存储 JWT 信息，适合微服务、分布式系统等架构，能大幅降低服务端存储压力；同时，通过严格的安全实践（如 HttpOnly Cookie、HTTPS、密钥管理），可构建起高可靠的 API 身份认证体系。
在实际落地中，需结合业务场景调整令牌有效期（如金融场景可缩短 JWT 有效期至 5 分钟），并搭配接口限流、IP 异常检测等措施，形成全方位的 API 安全防护网。
如果你需要将这个方案落地到具体项目中，我可以帮你整理一份JWT + Refresh Token 接口设计文档，包含登录、刷新令牌、登出等核心接口的请求参数、响应格式和错误码定义，需要吗？
编辑分享