jwt 的 token 被获取怎么办

@nightspirit 公私钥，对端公钥加密。

别搞那么多花样 SSL 是最稳的 诞生的目的就是为了解决不可信网络的可信通信
如果不支持 SSL 那就自己网络层加上公私加密 毕竟是经过全球验证的可靠通信算法

JWT 固然只是其中一个用户请求识别机制，还得配合其他手段判断是否异地或者换设备

系统安全不应该由一个小小的令牌来承受……被盗 1 次和 n 次是没区别的。

其实你的顾虑和 jwt 没关系，Cookie 认证同样有被抓包的风险，只要明确这一点再来想解决方案。
其实方案之一前面有说了，可以验证 IP，反代也是可以拿到 IP 的，需要让后端把 IP 通过 HTTP 头等方式传给你。

https：你当我不存在？
jwt：这个锅我不背。

所以为什么会被抓包？

@xuanbg 好的

@wei745359223 现在很少固态 IP 吧

用 https 就不怕被抓包了，卖软件给客户的时候就告知这点，不用后果自付。

JWT 的使用范围很窄

当然楼主的问题用 ssl 就行

jwt 被盗不久相当于账号密码被盗么？根据一样的逻辑处理就好了

一、token 有一个刷新有效期的，这个有效期过了，是无法进行刷新的。
二、用户反馈账号被盗后，应该要禁止用户登录。
三、将当前有效期内的 token 全部列入黑名单。

我就搞不懂了，为啥老是看到用 jwt 来做业务系统的身份认证呢（是用到业务系统上了把？应该把）？

非常赞同 @aboat365 老哥，我也看了不少开源系统，介绍中的技术选型，老是有 jwt 。

我个人 认为 jwt 的应用场景 非常狭窄，并不适合用来做 “XXX 管理系统”、“XXX 电商系统”，之类的。 有个场景，我觉得还是比较合适的，用户邮箱注册完，会有一封激活邮件，这个激活邮件中的激活地址后面跟的一串字符串，大概率是 JWT 的字符串。而且有效期可能就 4 小时，甚至 2 小时。

为什么呢？ 因为首先，就算邮件泄露，能造成什么损失？ 激活链接点进去，还需要比如一些关键信息的校验的。 甚至进去的页面中，姓名（昵称）之类的，都是脱敏的。其次，有效期也很短。最后的最后，这类邮件就算疯狂的发，对主业务系统没有任何影响。

当然如果有其他的 JWT 的应用场景也可以讨论一下，反正我是非常不赞成在业务系统中走 JWT 的，只有在一些 非重点（不一定是非重点，反正有个度把）的业务功能中，才可能有 JWT 。 业务系统还是 老老实实的 session （分布式 session ） ，或者 类似于 session 的 token 模式。

自定义 token 的模式不好吗，想单点登录，多端登录或者强制刷新都是可控的

Jwt 的应用场景是很小的，现在大部分的所谓 Jwt 都是伪 Jwt，很多系统还是存在中心验证服务器的。

70 多条评论看完了，说句实在话，楼主的问题是 JWT token 被获取后引发的一系列安全问题，我们以问题为导向进行反推，获取 token 必定存在一系列利益影响，试问，如果你的软件没有引发别人的利益，为何要获取你的 token 呢？ 难道只是闲的无聊？ 那么问题又来了，有利益存在，获取你的 token 进行下一步操作，是为了满足某个利益达成。如果没有利益别人也要获取你的 token，那基本上是无解，说的清楚点就是没有绝对的安全可言，token 只是一个签名用来校验你的服务的，仅仅是对自己的服务来说有一定安全校验，也只是达到了自己骗自己的目的，我可以第一时间获取你的 token 并解密后通过 token 解析的信息进行一系列的操作，这些都是可以反推的。

面试官：请你先回答在浏览器输入 URL 地址后，都发生了什么吧。

个人认为 JWT + 中心验证服务器的模式没有问题。个人实践中，将部分会话状态数据存放于 JWT 中来减少服务端的状态数据存储需求；中心验证服务器仅负责对 token 的有效性进行验证。

与自定义 token 模式进行对比，使用 JWT 作为 token 在主要认证逻辑上没有太大区别；优势在于将数据存储移到客户端后，减少了服务端在还原会话状态时所需的 IO 次数。至于对系统性能是否有根本影响，就见仁见智了。

上面说滥用 jwt 的我觉得很奇怪
jwt 只是一种可验证的信息签发传输方案. 你要在里面存储什么信息, 服务端如何利用完全是开发者自己的选择.
就算所谓要替代 cookie+session, jwt 可以替代的是 cookie 部分而不是整个 cookie+session. 纯 cookie 也是可以做无状态无 session 的身份验证方案的.

lz 的问题里就是服务端无状态导致无法踢人. 那就得重新做有状态认证方案了. jwt 可以+session 或者 anythin else 可用的服务端状态.