jwt 如何做在线踢人功能？

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

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

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

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

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

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

这就是 jwt 的缺点之一啊

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

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

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

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

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

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

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

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

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

jwt 就是无状态

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

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

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

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

@sblid 老哥，是这样的