快速参考

安全基础

• JWT 是签名的，而非加密的——任何人都可解码并读取载荷（payload）；切勿在其中存储密钥等敏感信息
• 必须先验证签名，再信任声明（claims）——仅解码而不验证对身份认证毫无意义
• alg: none 攻击：拒绝 algorithm 字段为 "none" 的 Token；部分旧版库曾错误接受未签名的 Token
• 使用强密钥：HS256 要求密钥长度 ≥ 256 bit；短密钥易受暴力破解

算法选择

• HS256（HMAC）：对称算法，同一密钥用于签名与验证——适用于单体服务场景
• RS256（RSA）：非对称算法，私钥签名、公钥验证——适用于分布式系统
• ES256（ECDSA）：相比 RSA 签名更小，安全性相当——在对体积敏感的场景中优先选用
• 绝不可由 Token 决定验证算法——服务端必须强制指定并校验预期算法

必需声明（Claims）

• exp（过期时间）：必须设置并验证——无过期时间的 Token 将永久有效
• iat（签发时间）：Token 创建时间——可用于实现令牌失效策略
• nbf（生效时间）：Token 在此时间之前无效——适用于定时访问控制
• 时钟偏差（Clock skew）：验证时间类声明时，应允许 30–60 秒的容差

受众（Audience）与签发者（Issuer）

• iss（签发者）：Token 的签发方——需校验该字段，防止跨服务 Token 盗用
• aud（受众）：Token 的预期接收方——API 应拒绝面向其他受众的 Token
• sub（主体）：Token 所代表的主体——通常为用户 ID
• Token 混淆攻击：若未校验 aud/iss，面向 Service A 的 Token 可被滥用于 Service B

Token 生命周期

• 访问令牌（Access tokens）：短期有效（5–15 分钟）——降低被盗后的危害范围
• 刷新令牌（Refresh tokens）：长期有效，须安全存储——仅用于获取新的访问令牌
• 刷新令牌轮换（Refresh token rotation）：每次使用后签发新刷新令牌，并立即作废旧令牌
• 撤销（Revocation）难度高——JWT 本身无状态；建议采用短有效期 + 刷新机制，或维护黑名单

存储方式

• httpOnly Cookie：可防御 XSS，但需额外防范 CSRF
• localStorage：易受 XSS 攻击，但在单页应用（SPA）中使用更简单
• 仅存于内存（Memory only）：安全性最高，但页面刷新后即丢失
• 切勿将 Token 存于 URL 参数中——会在日志、浏览器历史记录及 Referer 请求头中明文暴露

验证检查清单

• 使用预设的正确算法验证签名（切勿信任 Header 中的 alg 字段）
• 检查 exp 是否处于未来时间（考虑时钟偏差容差）
• 检查 iat 是否未明显过旧（可选策略）
• 验证 iss 与预期签发者一致
• 验证 aud 包含本服务标识
• 若存在 nbf，需一并校验

常见错误

• 在载荷中存储敏感数据——JWT 载荷仅为 Base64 编码，不具加密性
• 载荷过大——JWT 通常置于 HTTP 请求头中；多数服务器限制 Header 总大小为 8 KB
• 未设置过期时间——无限期有效的 Token 构成严重安全隐患
• 跨环境复用同一密钥——开发环境生成的 Token 可能意外在生产环境生效
• 记录（Logging）Token——Token 属于凭证类信息，应视同密码严格保护

密钥轮换（Key Rotation）

• 使用 kid（Key ID）声明标识签发该 Token 所用密钥
• 通过 JWKS（JSON Web Key Set）端点分发公钥
• 设置重叠期（Overlap period）：在切换至新密钥期间，同时接受新旧密钥
• 轮换完成后，已签发的旧 Token 仍将在其 exp 到期前持续有效——需据此规划业务逻辑

实现建议

• 使用成熟、经过审计的 JWT 库——切勿自行实现解析逻辑
• 推荐库：jsonwebtoken（Node.js）、PyJWT（Python）、java-jwt（Java）、golang-jwt（Go）
• 中间件应在执行任何业务逻辑前，尽早拒绝非法 Token