jwt 的 token 被获取怎么办

如果希望用 IP 方案的话，了解一下 X-Forwarded-For，整个链路上所有节点都遵守这个标准能解决很多问题。

不过用 IP 方案可能也解决不了你的问题，因为要考虑有些客户端会变 IP 的，一变 IP 就重新登录可能体验也不好。

可以考虑加个互踢，token 泄露一次，用户只需要重新登录就可以让以前泄露的 token 及其刷新产生的 token 全都失效。

token 这种方案其实保证使用 HTTPS 通信的话，一般是没问题的，客户侧的安全问题只能由客户自己解决，除非你提供专用终端。

另外就是可以增加偷到 token 后的使用难度，比如前端混淆代码对 token 和 payload 做个公钥签名，token 和签名一起发，后端私钥验证签名错误则认为 token 无效，只要你的混淆代码难以被逆向或外部调用，破解成本就会很高。

以前我的一些项目只是设置了一个刷新机制，token 有效期内被盗用挺无解的~

jwt 是无 server 的，注定没办法实现这种功能，如果想实现黑名单必定要破坏 jwt 的无 server，那其实和 cookie 也就没什么两样了。

有同样困惑，蹲一个。

JWT 因为 token 丢失就无法防范，造成 token 也不敢给太长时间。导致用户隔不久就得重新登录。这个体验缺陷不太好接受。

看看钉钉机器人的加签认证，developers.dingtalk.com/document/app/custom-robot-access

如果是拿着 token 做爬虫，那么可以随机在页面上做校验，如果是用模拟点击方式爬虫，那没办法，只能一定时间内限量请求。。。

加了 https 后能泄露的，都是故意把 token 提取出来的，这种你没办法再防了，是用户自己在攻击自己

你如果能知道这个 token 已经被盗了，那就是需要做 token 的黑名单，如果你不知道这个 token 是不是被盗了，那和 jwt 没啥关系。

有缘人啊，参考如下

Token Sidejacking¶

Symptom¶
This attack occurs when a token has been intercepted/stolen by an attacker and they use it to gain access to the system using targeted user identity.

How to Prevent¶
A way to prevent it is to add a "user context" in the token. A user context will be composed of the following information:

A random string that will be generated during the authentication phase. It will be sent to the client as an hardened cookie (flags: HttpOnly + Secure + SameSite + cookie prefixes).
A SHA256 hash of the random string will be stored in the token (instead of the raw value) in order to prevent any XSS issues allowing the attacker to read the random string value and setting the expected cookie.
IP addresses should not be used because there are some legitimate situations in which the IP address can change during the same session. For example, when an user accesses an application through their mobile device and the mobile operator changes during the exchange, then the IP address

解决不了。如果他想抓你包的话。
你这个问题背后，实际上背后是一个很大的问题，也可以说，不是问题。

个人认为，ip 可能会变，不可取。https 也照样抓包。
可以考虑再加盐 sign，然后再加上时间戳和随机字符串防重放。

如果没有 HTTPS 的话，和 JWT 没有任何关系，即使你每次都走验证流程，账号密码依然可能被中间人拿到，其结果是一致的，因此假设客户端、服务端可信，而信道不可信，则需要使用类似 HTTPS 的解决方案，比如应用发出请求时就 AES 一遍，如果客户端与信道均不可信，那么此题无解

加个黑名单就是了

这就是无脑用 JWT 的后果了。。。简单的说，JWT 不适合楼主这种需求。换成自己的轮子吧，用服务端存 Token 的虎符模式，别用 JWT 的这种无服务端的印信模式。

什么是虎符？古代将军领兵的信物。一半在实际掌握军队的军官手上，一半由皇帝临时授予领兵作战的指挥官。军官看到指挥官拿的虎符能与自己的合为一体，就听从指挥官的命令，否则就把骗子抓起来。

什么是印信？就是古代皇帝授予行政官员某地行政管理权的凭证。地方上官员认印不认人，所以西游记里面强盗杀了唐僧他爹，夺了印信就能堂而皇之地去上任。

“每次请求会续期” 这就是问题所在。

JWT 和 Session 的本质区别是什么？是 JWT 设计目的是“不需要中央服务器即可验证有效性”；签发在中央服务器，验证在业务服务器，不需要和签发服务器交互。由于其本质是离线验证，因此无法吊销。有那些个闲人搞出来 JWT 吊销机制完全破坏了这个设计目的，纯属闲的，直接用 Session 不好么。

那么如果不用那些个闲的卵疼的吊销机制，JWT 就只能使用“拒绝续期”机制。把 JWT 有效期设置得短一点，然后要求客户端频繁去「中央服务器」续期。当身份窃取时就拒绝续期。

而 LZ 是“每次请求会续期”，这说明什么？说明业务服务器能续期啊！这种行为完全破坏了续期机制的意义，还不如设置一个一百年的有效期，省得麻烦。

量子通信

https

曾经有个三哥面试官问过我这个问题
我说没办法
因为 jwt 不过存储，我发吊销
他表示不满意，但也没说怎么做

真没想到是个三哥

@wangyzj #38 要存储的 jwt 就变成了 session 注:存储 jwt 的黑名单一样是存储

好好的 cookie + session 方案你不用，学人家玩 token 。无状态 token 身份认证轻量是真的轻量，但弊端也不少啊。如果加入服务端续期什么，那还不如直接用 cookie + session，强行使用只不过造了个轮子。结合实际需求，选择技术方案。