@
seth19960929 5 分钟的延迟并不能满足常见的需求
比如，假设我登录了一个用户，拿到 jwt token ，此时点击注销，服务端加入黑名单。然后登录过程中 token 泄露或者前端只是选择性从 localstorage 删除，本质意义上服务端还存在。
因为黑名单查询不是即时的，那我就可以在服务端通过改密码方式修改用户的密码，然后重新登录，又可以拿到一个新的 token 。（当然有人会说改密码要二步验证之类的，这是另外一种做法和产品需求范畴了）
> 总之在有效期内仍可以做很多事情，或者不能使其立即下线，就有很多的安全隐患。
有人说你这个强依赖于状态, 不能用无状态做, 那可能确实。但目前的大多数产品提出的需求或者我做过的产品，基础都要满足我所说的即时性。（注销了这个 KEY 就无效了, 在任何层面上他能操作能认证就是一个 BUG ）
我看了楼上，思考过确实对用户的系统不适合做 jwt ，只适合真正意义上的无状态需求（下载站鉴权、cdn 鉴权之类的、这些太少了，我基本没接触过）。而只适合所谓第三方鉴权的，服务对 服务之间的鉴权。
虽然我也在用 jwt 、而且每次请求都必命中 redis 查验黑名单，99%请求命中一次数据库。
大部分接口都需要获取用户的自身信息，为什么用户信息不全部存到 jwt ？因为不及时不可靠。
有人说你这样用 jwt 比传统 token 都麻烦，存储的还多几倍的黑名单还基本都要查 redis 、数据库，何必 jwt ，但 jwt 能够方便对接前端及第三方这种共识特性，迫使选择了 jwt 。
总之一句话，我不觉得 jwt 很好，我也觉得一身诟病。我选择 jwt 唯一的技术优势就是它只存黑名单，而传统 token 存白名单。能省点存储就省点吧。