JWT 认证与 OAuth2.0 最佳实践:从原理到安全防线的完整构建
用户认证是每个 Web 应用的基础设施。传统的 Session 方案依赖服务端存储,而 JWT 提供了无状态方案——Token 本身携带用户信息,服务器不需要查数据库就能验证身份。
JWT 的结构
JWT 由三部分组成,用 . 分隔:Header(签名算法)、Payload(携带信息如 sub/iat/exp)、Signature(防篡改签名)。
Access Token + Refresh Token 双令牌策略
这是生产环境的标准方案:
- Access Token 有效期短(15 分钟),暴露风险低
- Refresh Token 有效期长(7-30 天),用于静默续签
- Refresh Token 应存储在 httpOnly Cookie 中而不是 localStorage
用户在 Access Token 过期后,前端自动用 Refresh Token 换取新的 Access Token,整个过程对用户完全透明。
安全防线
密钥管理
永远不要把 JWT Secret 硬编码在代码里。使用环境变量 + 密钥轮换策略——部署时同时支持新旧两个密钥,过渡期结束后废弃旧密钥。
Token 存储对比
| 存储方式 | XSS 风险 | CSRF 风险 | 建议 |
|---|---|---|---|
| localStorage | 高 | 无 | 不推荐 |
| sessionStorage | 高 | 无 | 不推荐 |
| httpOnly Cookie | 无 | 有 | 推荐(需 CSRF 防护) |
| 内存变量 | 无 | 无 | 最安全 |
CSRF 防护
如果使用 Cookie,必须加 CSRF Token 双重验证——请求头和 Cookie 各带一份 token,服务端比对一致才放行。
OAuth2.0 授权码流程
OAuth2.0 不是认证协议而是授权协议——让第三方应用在用户授权下访问受保护资源。
流程:用户授权 -> 返回授权码(一次性)-> 客户端用授权码换 Access Token + ID Token(JWT)。
最关键的安全要点:永远在服务端验证 ID Token 的签名和声明(iss/aud/exp),不要信任客户端传来的任何身份信息。
总结
JWT 让认证变得无状态,但无状态不等于无顾虑。双令牌策略平衡安全与体验,httpOnly Cookie + CSRF Token 是大规模应用的标准配置,密钥轮换是长期维护的必需手段。认证安全没有银弹——但有一层又一层的防线。
本文是原创文章,采用CC BY-NC-SA 4.0协议,完整转载请注明来自CC 的技术工坊
