jwt 的 token 被获取怎么办

@karloku 同感。问题和 jwt 根本没有关系，抓包的场景下，cookie 中的 session 不也同样能被抓包么。而且奇怪的是，为何很多人觉得加上刷新机制后就能防止抓包呢，刷新过程不也会被抓包么。我认为关键还是在于解决抓包。

解决中间人抓包（比如路由器抓包）：上 https，这样可以防止中间人抓包。
解决客户端抓包（比如爬虫）：本质上是人机识别，用验证码、行为识别那套。
以上和 session 、jwt 刷新都是无关的。

动态 token 里面包含一些验证信息， 比如 session 类信息，ip bind 类信息， 指纹类信息， 时间类信息（动态更新）， 把这些信息编码， 代码一定要做一些混淆或加密。ip 类目前国内的网络环境不可靠， 有的 ip 是集体 ip 有的是浏览器自己中转的流量。

这和 jwt 没关系，本质上是传输层不安全导致身份识别令牌泄漏，用不用 jwt，设置多久吊销，有没有黑名单，只要不解决传输层不安全的问题，无解。

你要想的是为啥会被抓包，https 就不需要考虑被抓包了；

无解

jwt 解决的是用户是否已认证的问题，你的问题是用户究竟是不是他本人，这是两个事

考虑场景：一般情况下，用户是长期登录的，而且认证信息不会被轻易被盗，但是仍然存在一部分用户有登出账户的需求（手机被丢等）。
相对于当前长期在线的用户而言，需要登出的用户只是很少的一部分。（这跟现在的证书颁发是很相似的，大多数人都会妥善存储私钥，但是仍然有一部分人的私钥马大哈丢失了）

这时候可以使用 jwt 作为用户令牌，使用 redis 等来存储被吊销的 jwt id 。
这样做主要是可以有效的减少热数据的数据库大小，降低对数据库系统的压力。而且，这个吊销列表也完全没有必要实时更新，隔一段时间向认证服务器更新一下数据即可。

如果你的应用用户量并不是很大，或者对登出的实时性要求很高（银行类），jwt 其实并不是一个适合你的方案，随机生成一个 token 可能更好。

@knives
@karloku
@reself
非常正确，这道问题我没看懂和 JWT 有什么关系

@Dragonphy 合到 token 了 refresh_token 应该也能拿到吧，这样，就直接完蛋了吧

@xuanbg 这类比虎符模式怎么理解？指挥官去皇帝领凭证，去军官验证，验证过了获得指挥军队的资源。我怎么看就是 jwt 呀。

服务器为啥一直续期。。一个 token 用一辈子？这样不好吧。。
1 、选择客户端续期
2 、选择添加一个 refresh_token 参考 Spring Security