jwt 如何做在线踢人功能？

[SkyLine7]

不依赖第三方中间件（比如 redis ）

[bootvue]

必须依赖中心化的存储机制

[Pythoner666666]

不配合第三方中间件做不到

[JoeDH]

token 存在哪，那就在哪把 token 删掉

[codehz]

还是需要一个地方存 revocation list （）
相比于其他不透明 session 来说，revocation list 可以在后端用 bloom filter 做初筛（因为数量上 revoke 的肯定比较少，分发 bloom filter 的状态更便宜）

[wu00]

玩骚的是吧，一次性 token ，从签发处来控制

[BBCCBB]

redis 记录这个 token 是否还能用. 白名单/黑名单都可以.

[nikenidage1]

这就是 jwt 的缺点之一啊

[thinkershare]

Jwt 主要用来给资源授权的，生命周期很短。几乎不做权限回收控制。如果想要做有状态的会话凭证，又不想维护服务器状态，理论上就是矛盾的。

[luckyrayyy]

无状态怎么记录状态？开着车怎么走路？

[cp19890714]

办法：可以把 JWT 标签存储到服务端，用户访问时，校验当前状态是否有效，如果无效，就禁止访问。

另外，需要踢人，就不应该用 JWT 。JWT 滥用，V 站都说了很多次了。

[sblid]

既然需要状态就不要用 jwt ，否则自己重新实现了一个 session ，不是没事找事么。

[nothingistrue]

做不了。JWT 只是个 Token ，不要只用它来做会话跟踪。在线踢人属于会话跟踪，必须上服务器端会话管理。

[xiaogezz]

JWT 只做好认证的事情就好了，至于具体的访问权限，应该交由权限控制

[ns09005264]

我有个想法，那就是做和 session 相反的事，即：把要踢的用户保存在内存里。
具体是这样的：
用户改了密码或者要踢某个用户下线，就把该用户的 ID 保存到内存里，因为要踢下线的人一般都是少数，费不了多少空间。
当然要设置保存期限，和 JWT 的过期时间一样就行。
比如用户改了密码，就把他的 ID 保存到内存里，当他依然用旧令牌访问时，后端从旧令牌中解析到他的 ID 并与内存中的列表比对，如果存在就令牌失效，需要登录，同时删除列表里的 ID 。
如果他改了密码，但再也没有登录过刷新令牌，那么也无妨，因为内存中的列表过期也会清理的。
简单来讲，因为 JWT 对后端服务是无状态的，但可以在后端增加“踢人列表”这一点点不怎么占用资源的状态。
以上没有考虑分布式的情况，因为我没有分布式的经验。分布式的“登录与验证服务”应该也是单机的服务吧？

[Breacher]

一直都是只把 JWT 当作 token 用，然后使用数据库跟踪它的状态：已退出、已 revoke 、重置密码后让旧 token 失效。我只是需要 JWT 的一些特性，比如能够携带一些键值对、能够验证签名（签名验证不通过直接返回未登录，避免将压力给到存储层）。

[streamrx]

jwt 就是无状态

[NX2023]

JWT 是没法撤销的，如果不依赖缓存，只能使用长短 JWT
在线踢人是不行的，只能说把短 JWT 设置的短一些，比如 1min 或者 30s

https://nickxu.me/post/jwt-refresh-token

[fordoo]

提供一个思路，jwt payload 中保存一个用户的关键信息的签名，每次验证 jwt 的时候，同时去验证 db 里面用户的这个签名（可以加缓存减少 db 压力），需要踢 jwt 时，只需要让用户的关键信息变化就行

[hyperbin]

在用户表维护个 tokenStartTime ，鉴权时判断 jwt 的 iat 是否大于 tokenStartTime ，只要更新 tokenStartTime 到当前时间就可以拉黑以前签发的所有 token

[NX2023]

@sblid 老哥，是这样的

[XCFOX]

@fordoo #18

jwt 的出现就是为了无状态、不访问 db 。既然业务需求不能无状态，不如直接把 jwt 的签名、验证这一套省略了。用最简单的最直观的 session 模式。

[chendy]

直接不用 jwt ，jwt 本身就适合在服务间传递，减少用户中心这类服务的压力
浏览器，客户端认证用普通的 token （ cookie 里的 sessionid 也算 token ）

[PVXLL]

打电话给客户端使用者让他自己销毁

[zsdroid]

@ns09005264 负载均衡了解下

[aladdinding]

加一个黑名单的中间价

[mdn]

@fordoo 这样用户的其他端都会被踢掉，所有 token 失效，而不是单个

[hongfs]

十月份才过去几天，第几个 JWT 帖子了。。。

[manasheep]

token 时限设短，只有高危操作去验证用户账户状态，别的默认提供服务就可以了

[hez2010]

其实最好的方法是不用 jwt

[lidashuang]

黑名单, 数据库存储黑名单

[fire2y]

换个思路 把权限给禁掉就好了

[cslive]

数据库总用的吧，数据库中拉黑

[leegoo]

因为 jwt 就是一个 token ，token 反解析出来可以获取到用户信息

数据结构类似于 ： key:token ,value:info

我提供的思路是

在获取到 token 后，再使用另外一个 map 存储，这个 map 的 key 是 用户账号（保证用户的唯一性即可），value 对应这个 token
这样就能够保证 ，知道哪些用户登录了，如果要踢人， 只需要根据 新定义的那个 map 找到 对应的 token (可能有多个)， 从 map 或者 redis 清理掉即可

[chenduke]

1.缩小 token 的过期时间，10 分钟，5 分钟。3 分钟， 看具体的场景的需要。
2.token 中包含生成的时间， 刷新 token 的时候与数据库中的最新刷新时间做比较，如果小于则返回需要重新登录。
3. 上面二条并不能保证及时性， 有条件加个消息推送的机制，这样就很及时了。

[version]

@hongfs 生活压力大..最近太多人转行程序员了..只能找一些 10 年未维护的老旧项目接手(面试的人也不懂技术)...产品就会把遗留问题丢给新手..

[fengpan567]

把用户禁了

[fregie]

这个需求跟 jwt 存在的意义互斥

[swulling]

一个令人费解的设计就是明明服务请求都落中心数据库，别人建议用 redis 做个 session ，却说 jwt 适合分布式，没有单点。很奇怪。

[sunmlight]

判断 用户+签发时间， 早于“踢”的失效？

[Tiny]

把 signing key 删了，token 失效

[fanchenio]

你是否在搜索 session ？

[zhiyu1998]

satoken

[pannanxu]

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

[summerLast]

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

[fuchish112]

不要用 jwt

[bill110100]

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

[IvanLi127]

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

[wunonglin]

典型的 JWT 滥用例子

[Dlin]

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

[GTim]

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

[matrix1010]

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

[xuanbg]

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

[iwdmb]

配合数据库

[gitrebase]

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

[byaiu]

建议看这个帖子

https://v2ex.com/t/979326

[kwanzaa]

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

[ionfev]

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

[expy]

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

[justfindu]

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

[jonsmith]

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

[8355]

你们的 jwt 不校验的吗？？？？
震惊了。。。

[bk201]

定时换密钥，但是会把人全踢了。

[nobject]

个人觉得加个黑名单就简单，要踢人，或者后台删除一个用户，用户修改重置密码等，都可以把这个用户加入到黑名单中。依靠 jwt 本身的功能，只能有效期设置短点吧

[neptuno]

加个 jwt 黑名单

[Torpedo]

核心就是有没有查库呗。把你的 jwt 校验增加查库的这一步应该就可以了

[tairan2006]

我工作这么多年就没用过 jwt…

[pengxiaoyu]

我的理解是 jwt 解析->userid+roleid 等信息，那这个用户是否是黑名单用户，是由用户服务告诉我的。拦截器里查询用户服务告诉我是否要把他踢掉。而用户服务是否去查表还是查 Redis ，和网关无关，网关只做了从 jwt 解析这一步。

[mxT52CRuqR6o5]

恭喜你，用一种很别扭的方式重新实现了 session

[coala]

退而求其次，

当前时间之前的 这个用户的签发 jwt 全部拉黑， gateway 加个逻辑判断就好了吧 。

直接把这个用户所有的 token 的全干掉。

[BeautifulSoap]

jwt 无状态，本质和互联网初期时，网站在 cookie 里塞用户 id 服务器靠 cookie 里记录的用户 id 来确认你是哪个用户没区别。只不过 jwt 更现代而且往往有效期非常短
想要在服务器端实现 jwt 无效化，最后搞到最后你会发现这就是 session

[SuperXRay]

不摄入食物的话怎么吃饱（不依赖注射营养物质）

[lmq2582609]

jwt 就是个字符串，不依赖 redis ，那只能用程序的内存来代替 redis 了，需要持久化的话得自己实现。

[shea]

可以做个拉黑功能, 在验证 jwt 前面加个中间件验证如果在 redis 里面存在的 token 就直接返回 401 就可以了