要做实时登出的客户端 API，是不是完全不适合 JWT 鉴权？每个请求都要验证 token 有效性，传输和验证签名看起来是在浪费资源

RT

你这个就别用什么 JWT 了，一个 sessionId 发给用户，然后后端根据这个 id 来读取用户权限进行鉴权就好了。把一堆的授权信息放在 JWT 里面，纯纯的浪费流量

有 refresh  时间短点就搞定啊

jwt 压根不适合普通的用户登录，应用场景也非常有限，像是 ruoyi 系统这种用 jwt 作为普通 token ，只增加了解析复杂度和 token 长度这些缺点，换成随机字符串要好很多。

即使这样我觉得用 JWT 也不是不行：
1. JWT 有标准化的规格说明，IETF RFC ；
2. 没必要为了节省传递 token 的那点流量把自己的路堵死，日后万一需要无状态降级也有机会；

jwt 的设计理念就是无状态呀，你这“登出”的功能本身就是有状态的设计。
如果强行使用 jwt 来做登录、登出，那么必然后台要维护一个 jwt 的黑名单，这就又把状态引入回来了

直接用 session 就好了

jwt 主要是用于资源鉴权使用的，登录状态的保留最佳实践就是 session 。我司 PHP 就是把 jwt 当 session 使用，导致服务器要踢用户下线时（改密码、修改权限）非常麻烦。

可以，在下发 jwt 前先存储 tokenid ，用户登出后销毁 tokenid,不过这样事实上也就变成 session 了，如果 tokenid 过期时间长的话可以用黑名单，时间短的话还是仅记录每个用户最新的 tokenid

@wxf666 #11 放到 redis 的话，就是 session 了

@excxapp 如果每个请求，都要去 redis 判断一下，是否登出了，

为何不把 JWT 里的内容，挪到 redis 里，拿不到就是登出呢？

这样，每个网络请求能更小，带宽需求更低呀？

jwt 是无状态的，踢人不适合 jwt ，用黑名单反而复杂了