如何保障JWT Token安全，防止其被复制到其他计算机使用？

先把核心矛盾说透：现在的问题根本不是HS256算法不安全、也不是SSL部署不到位，而是JWT作为一个独立的字符串令牌，只要被完整从本地存储里抠出来，单纯靠换存储位置根本挡不住它被复制到别的设备滥用——不管你存Cookie还是LocalStorage，只要是持久化存储，就有被XSS脚本、本地恶意程序完整读取的可能，偷到的人在5分钟有效期内，拿着这个合法令牌直接请求，不做额外校验的服务端肯定会放行。

核心防护逻辑 #

要让偷走的JWT在别的设备上失效，核心是不要把所有身份校验信息都塞在自包含的JWT字符串里，要让令牌的有效性和原设备的不可导出的内存上下文强绑定，让偷到的JWT脱离原设备就成了没有配套凭证的废字符串，具体可以按三层逻辑落地：

• 1. 加无持久化的派生密钥绑定校验
  调整现有HS256 JWT的签发流程：
  1. 用户登录拿到核心身份凭证后，前端先在浏览器内存（闭包变量、非持久化的内存映射，绝对不写入LocalStorage/Cookie/SessionStorage）生成一个128位长度的随机派生密钥。
  2. 把这个派生密钥和采集到的低敏感度设备特征（浏览器UA、时区、屏幕色彩深度、无隐私风险的硬件属性值）做SHA256哈希，将哈希结果作为自定义声明写入JWT，一起用HS256算法签名返回。
  3. 前端把签好的JWT做持久化存储，但每次发请求的时候，要结合内存里的派生密钥、当前请求时间戳、请求参数做HMAC-SHA256计算，把结果放到自定义请求头（比如X-Request-Proof）里，和JWT一起发给后端。
  4. 服务端校验分两步：先验JWT本身的签名和5分钟有效期，再用JWT里存的设备特征哈希、前端传来的证明值，反向推导派生密钥做匹配校验。如果攻击者把持久化存的JWT完整复制到其他设备，他根本拿不到只存在原设备内存里的派生密钥，算不出合法的请求证明，服务端会直接拦截。
• 2. 搭配服务端的异常迁移实时检测
  不用完全依赖JWT的无状态特性做校验，可以搭配TTL和JWT有效期完全一致的轻量缓存（比如Redis）存校验标记：
  1. 每次JWT签发时，利用JWT自带的jti唯一标识，把jti和绑定的设备特征哈希值写入缓存，设置5分钟自动过期，不需要存全量会话信息，只存这组映射关系就行，性能开销可以忽略。
  2. 每次收到请求完成JWT基础校验后，提取当前请求的设备特征和缓存里的绑定值做比对：如果发现同一个jti发起的请求，设备特征和原绑定值完全不匹配，立刻把这个jti标记为永久失效，后续所有带这个令牌的请求全部拒绝，不管剩余有效期还有多久。
     这种方式相当于给被偷的JWT加了“自毁开关”，只要检测到令牌跨设备迁移，立刻作废，把攻击窗口压到0。
• 3. 补全基础防护，缩小令牌被窃取的范围
  就算做了上面的绑定逻辑，基础存储安全也不能省：
  • 要是用Cookie存JWT，必须给Cookie加上HttpOnly、Secure、SameSite=Strict三个属性，避免令牌被前端脚本读取、在非HTTPS链路传输、被跨站伪造请求利用。
  • 站点配置严格的CSP策略，禁止内联脚本执行、禁止加载未审计的第三方脚本，从根源上拦住XSS注入路径，减少恶意脚本读取本地存储令牌的概率。
  • 保持现在5分钟的短有效期设计，后续可以配合静默刷新机制：连续3次通过设备绑定校验的合法请求，可以自动给当前设备签发新的短有效期JWT，不用频繁让用户重新登录，不影响体验。

常见的无效防护误区 #

注意，下面这些看起来合理的方案，根本挡不住JWT被复制到其他设备滥用：

• 把JWT加密后存在LocalStorage：加密密钥本身就是写在前端JS代码里的，攻击者只要能读LocalStorage，就能从JS里抠到解密密钥，解出完整的合法JWT，复制到别的设备照样能过基础校验。
• 给JWT绑定客户端IP做校验：普通用户的IP会因为网络切换频繁变动，很容易造成正常用户被误拦，而且攻击者只要把请求代理到原IP出口，就能轻松绕过校验。
• 升级JWT的签名算法强度：HS256本身的抗伪造能力已经足够，问题从来不是签名能不能被破解，而是被偷走的JWT本来就是服务端合法签发的，签名是对的，再强的算法也挡不住合法令牌被复制滥用。

内容的提问来源于stack exchange，提问作者Alvin Quezon