jwt 如何做在线踢人功能？

你是否在搜索 session ？

satoken

可以实现一个伪需求：使用 socket 推送，前端收到消息后执行踢出逻辑。这样需求可以实现，但如果手动保留 token 还是可以登录。

后台部署一个用户请求 401 (代价是所有用户的请求的 token 都做了验证)
前台 401 清除 token

不要用 jwt

@ns09005264 不管是记录白名单还是黑名单，都需要一个记录的地方。对于分布式系统，还是需要每次使用前去记录的地方查询对比，和 session 方案没本质区别。

等过期就行了，access token 最多也就活几分钟。不想等就别作死用 jwt 。或者 jwt payload 里加个 version ，给所有人签发下一 version 的 token ，服务端直接把不是最新 version 的 token 拒绝掉。

典型的 JWT 滥用例子

简单，先这样，再这样，然后那样

楼上都没把数据说明白。JWT 是可以先获取到用户数据，然后从数据库里抽出用户数据再验证的，所以，最简单的方案，就是生成的时候加一个用户的 salt 进去，如果要踢出用户，只要改变这个用户的 salt 即可

假设踢人是低频操作。 有数据库，签发 token 可控的情况下感觉可以这样: 把用户分为 n 组, 每组存个 version 到数据库里，签发 jwt 的时候把用户组的 version 也带上。踢用户时用户组对应的 version+1 。服务器每分钟同步整个用户组/version 表到内存(或者用 mq 实时性更高)，解析 jwt 时对比内存里的 version 和 token 里的 version ，不匹配就走数据库查询用户有没有被踢。比如 1000 万用户分 1000 组，最坏情况就是这一组的 10000 个用户同时请求

JWT 做不到有状态。所以，正确的做法是放弃 JWT ，自己实现一个有状态的 token ，非常简单。

配合数据库

op 这个需求有点矛盾，主要在与“在线踢人”是一个 stateful 的操作，而 JWT 最大的卖点就是 stateless ；可以考虑放弃 jwt 使用 session ；如果真要做的话就只能用一些存储中间件吧，想不到别的比较好的方案了

建议看这个帖子

https://v2ex.com/t/979326

灰名单，查一下又不会死。

JWT 是个字符串，是服务端使用密钥单向哈希计算出来的。按理说前端用后端给的 Token 字符串请求，服务端只验证，不保存状态，适合多个后端的分布式。但是呢，后端从来不信任前端（虽然说 Token 是后端生成的，所有的接口后端都要验证判断），所有一般还是后端使用 Redis 保存 Token 的有效期，所以对于踢人功能来说，删除后端 Redis 里的 Token 就行。

服务端加上状态管理，然后就成了自己发明的半吊子 session 。

每个用户本地文件系统存一个私钥, 踢人就删私钥, 无法解码就失效. 下次登录创建新私钥保存. 私钥名可以使用 userId_hash(token), 删除时候查找 userId_* , 你看是不是可行.

Jwt 有效期尽量短一点，比如 30 分钟、1 小时，使用 refresh_token 刷新 Jwt token 时，再处理踢人逻辑。
本质上，Jwt 授权签发后不能直接取消了，只能等过期重新签发。