JWT在OAuth中用于身份验证，前端需安全存储于HttpOnly Cookie或内存，避免localStorage以防XSS；使用时校验过期时间与签名，配合刷新机制和多层防御策略保障安全。
在现代Web应用中，用户身份认证是核心功能之一。JavaScript前端常与后端配合实现OAuth流程，并使用JWT（JSON Web Token）作为认证令牌。但如何安全地获取、存储和使用JWT，直接影响整个系统的安全性。
JWT在OAuth中的角色
在OAuth 2.0流程中，前端（如单页应用）通常通过授权码+PKCE模式从认证服务器获取访问令牌。这个令牌通常是JWT格式，包含用户信息、过期时间、签发者等声明。
JWT由三部分组成：头部、载荷和签名。服务端签发后，前端将其用于后续请求的身份验证，一般放在Authorization头中，形式为Bearer 。
注意：JWT本身不加密，仅签名防篡改。敏感信息不应放入载荷，除非额外加密（JWE）。
立即学习“Java免费学习笔记（深入）”；
前端存储JWT的安全方案
前端存储令牌的方式直接决定其是否容易被窃取。常见做法有：
- 避免localStorage：虽然方便，但易受XSS攻击。一旦页面存在脚本注入漏洞，恶意JS可轻易读取并发送令牌。
- 推荐HttpOnly Cookie：后端在登录成功后，将JWT写入带有HttpOnly和Secure标志的Cookie。这样JavaScript无法访问，XSS无法窃取。同时设置SameSite=Strict或Lax，防止CSRF。
- 内存存储 + 刷新机制：若必须用localStorage，可考虑将完整JWT存于内存变量，仅将加密后的标识存在storage。每次刷新时通过短期刷新令牌（refresh token）重新获取，减少暴露窗口。
前端使用JWT的注意事项
即便存储安全，使用过程仍需谨慎：
- 检查JWT过期时间（exp字段），提前触发刷新逻辑，避免请求失败。
- 不要信任JWT中的任何数据而不验证。服务端必须校验签名，并检查iss、aud等字段。
- 敏感操作（如修改密码）要求用户重新认证，不能仅依赖长期有效的JWT。
- 登出时，若使用HttpOnly Cookie，应调用/logout接口让服务端清除会话；若用内存存储，清空变量并删除storage内容。
增强整体安全性的建议
单一措施不足以保障安全，需多层防御：
- 启用CSP（内容安全策略），限制外部脚本加载，降低XSS风险。
- 使用Subresource Integrity（SRI）确保引入的第三方库未被篡改。
- 后端设置合理的令牌有效期，短期access token搭配长期refresh token，并记录refresh token的使用状态。
- 对高敏感操作启用二次验证（如短信、TOTP）。
基本上就这些。安全不是一劳永逸的配置，而是贯穿开发、部署、监控的持续过程。选择合适的JWT存储方式，结合OAuth最佳实践，才能构建真正可信的认证体系。
