JWT是一种无状态认证机制，由Header、Payload和Signature三部分组成，适合分布式系统；相比传统会话无需服务端存储，但需防范XSS和令牌无法主动失效问题，建议结合HttpOnly Cookie与refresh token机制提升安全性。
JWT（JSON Web Token）在现代Web应用中被广泛用于身份认证和会话管理。它是一种轻量级、自包含的令牌格式，能够安全地在各方之间传输信息。与传统的基于服务器的会话管理不同，JWT 提供了一种无状态的替代方案，特别适合分布式系统和前后端分离架构。
JWT 的结构与工作原理
一个 JWT 通常由三部分组成，用点（.）分隔：
- Header：包含令牌类型和使用的签名算法（如 HMAC SHA256）
- Payload>：包含声明（claims），比如用户ID、角色、过期时间等
- Signature：对前两部分使用密钥签名，确保令牌未被篡改
例如，在 JavaScript 中生成或解析 JWT 时，常使用 jsonwebtoken 库（Node.js 环境）：
const jwt = require('jsonwebtoken');
// 签发令牌
const token = jwt.sign({ userId: 123, role: 'user' }, 'your-secret-key', { expiresIn: '1h' });
// 验证并解析令牌
jwt.verify(token, 'your-secret-key', (err, decoded) => {
if (err) console.log('Token 无效');
else console.log('用户信息:', decoded);
});
JWT 与传统会话管理的对比
传统会话依赖服务器存储 session 数据，通常通过 cookie 保存 session ID。而 JWT 是无状态的，所有必要信息都编码在令牌中。
立即学习“Java免费学习笔记（深入）”；
- 传统会话：数据存在服务器，安全性较高，但扩展性差，不适合多节点部署
- JWT：数据存在客户端，服务端无需存储，易于横向扩展，但需注意令牌一旦签发无法主动失效
因此，JWT 更适合 API 认证，尤其是 RESTful 接口或微服务场景。
JWT 在浏览器中的存储与安全
前端获取 JWT 后，常见存储方式有：
- LocalStorage：方便访问，但易受 XSS 攻击
- HttpOnly Cookie：防止 JavaScript 访问，抵御 XSS，推荐用于敏感环境
- 内存变量：关闭页面即丢失，安全性高但体验较差
建议结合使用 HttpOnly Cookie 存储 JWT，并配合 CSRF 保护机制，提升整体安全性。
刷新与失效机制的设计
由于 JWT 本身难以主动注销，需设计合理的刷新策略：
- 设置较短的过期时间（如 15 分钟）
- 配合 refresh token，存储在 HttpOnly Cookie 中，用于获取新的 access token
- 维护黑名单或使用短期黑名单机制处理登出后的令牌
这样既保持了无状态优势，又增强了安全性。
基本上就这些。JWT 是一种强大且灵活的认证方案，但在使用时必须权衡便利性与安全风险，合理设计令牌生命周期和存储方式。不复杂但容易忽略细节。
