JWT Access Token 被窃取的风险与解决方案
文章目录
- JWT Access Token 被窃取的风险与解决方案
- JWT Access Token 被窃取后会产生的问题
- 解决方案
- 1. HTTPS（TLS 加密）
- 2. HTTP Only + Secure Cookie
- 3. 短期有效期（Short Expiry）
- 4. 声明验证（Claims Validation）
- 5. 客户端指纹绑定
- 6. Token 撤销列表（JWT Blacklist）
- 7. 使用次数限制
- 8. 动态 Token（Rotating Token）
- 9. Proof Key for Code Exchange（PKCE）
- 10. JWT Refresh Token
- 实际开发当中的部署建议
JWT Access Token 被窃取的风险与解决方案
上周在面试的时候被问到了这个问题，我只回答上来了 JWT Access Token 进行无状态认真的原理，但是针对具体的问题完全没有思路，因此通过这篇文章进行整理。
JWT Access Token 被窃取后会产生的问题
- 身份冒充：盗窃者可以通过 JWT 冒充被盗取的用户；
- 数据泄露：攻击者可以访问用户的敏感数据，如果 JWT 的 PayLoad 中直接包含用户的敏感数据，那么攻击者可以直接对 PayLoad 进行解码来获取敏感数据，否则攻击者可以通过 JWT 登录以访问用户的隐私数据；
- 权限提升：如果 token 包含高权限，攻击者可执行危险的操作；
- 会话劫持：JWT 被窃取后，攻击者可以完全控制用户的会话；
- API 滥用：利用合法 Token 进行 API 滥用。
解决方案
1. HTTPS（TLS 加密）
HTTPS 协议可以在数据传输过程中对数据进行端到端的加密。
基于 HTTPS 协议进行通信可以防止中间人攻击，避免 token 在传输过程中被明文截获。
现代浏览器已经对非 HTTPS 网站标记为“不安全”，强制加密成为标配。
基于 HTTPS 加密，即使攻击者窃取到饿了数据包，也无法解密 TLS 加密的内容。
2. HTTP Only + Secure Cookie
HTTP Only
HTTP Only 是一种 Cookie 属性，设置后表示该 Cookie 只能通过 HTTP 协议传输，无法通过客户端脚本（比如 JavaScript）访问。
设置 Cookie 属性的 HTTP Only 可以防御 XSS 攻击。
Secure Cookie
Cookie 的 Secure 属性表示 Cookie 只能通过 HTTPS 加密连接传输，防止在明文 HTTP 中泄漏。
3. 短期有效期（Short Expiry）
为 JWT Access Token 设置较短的有效期。
- 缩小攻击的窗口期，即使 Token 被窃取，攻击者的使用时间也有限；
- 需要配合 Refresh Token 使用，不影响用户体验；
- 统计显示 90% 的 Token 滥用发生在窃取后的几分钟内。
4. 声明验证（Claims Validation）
指的是服务端严格验证 Token 中的声明。
5. 客户端指纹绑定
将 Token 与客户端特征绑定。
- 当 token 在不同设备/浏览器使用时会被拒绝；
- 即使 token 泄漏，攻击者也难以复制被窃取方完整的客户端环境；
- 可检测 99% 的异地登录行为。
6. Token 撤销列表（JWT Blacklist）
Token Blacklist 属于 JWT Access Token 的主动防御机制，其工作流如下：
客户端 -> [Access Token] -> 网关↓[检查Redis黑名单]↓[有效:放行 | 无效:401]
它具有以下特点：
- 即时响应：Redis 查询；
- 可拓展：TTL 自动清理过期条目；
- 微服务友好：集中式管理；
7. 使用次数限制
如果携带某个 JWT 的 HTTP 请求次数超过阈值，对其进行限流。
8. 动态 Token（Rotating Token）
每次请求后返回新的 token，旧的 token 立即失效，客户端必须持有持续更新的 token 才能过访问。
优势：
- 单个 token 有效期只有单次请求；
- 即使 token 被截获，攻击方也无法正常使用，因为被窃取者单次请求之后上一次的 token 就过期了；
动态 Token 适合金融级的安全要求。
9. Proof Key for Code Exchange（PKCE）
OAuth 2.0 增强流程：
- 客户端生成
code_verifier和code_challenge； - 授权请求携带
code_challenge； - Token 交换时验证
code_verifier。
10. JWT Refresh Token
Refresh Token 是现代认证系统中关键的组件，它通常与 Access Token 配合使用，在安全性与用户体验之间取得平衡。
双 Token 的设计如下：
| Token 类型 | 用途 | 生命周期 | 存储位置 |
|---|---|---|---|
| Access Token | 访问资源 | 生命周期 | 短（分钟级） |
| Refresh Token | 获取新的 Access Token | 长（天/月级） | 安全存储 |
双 Token 的典型工作流：
双 Token 的安全设计原理
- Access Token 短期有效：即使泄漏，攻击者只能在有限时间窗口内发起攻击；
- Refresh Token 长期有效：只能用于获取新的 Access Token，不能直接访问资源。
实际开发当中的部署建议
基础防护（所有项目必备）
- 强制 HTTPS；
- HTTP Only + Secure Cookie；
- 设置 token 有效期为 15 ～ 30 分钟；
- 基本 claims 验证。
中级防护（敏感业务）
- 客户端指纹绑定；
- 异常使用监控；
- 关键操作二次验证。
高级防护
- 动态 Token 轮换；
- PCKE 流程；
- 硬件绑定；