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

我觉得只跑一个实例单体应用都不适合。其他情况或许有适合的用例。
要用 jwt 实现的话，做 token 黑名单查也能做出实时的效果。

不合适

登录还是 session 做吧。

感觉除非分布式要求非常高，无数台机子要分布式验证，真心不如 session

JWT 有个办法,就是针对 token 增加时间戳,每次删除后,更新最新的时间戳,然后存到 redis 里面,比较时间戳之后的即可

@excxapp 这不就是 session 吗？这样有啥意义，用着 jwt 但是自己造了个 session ？

想法很好，设计是可行的。不过有点需要注意，如果权限数据很多，不建议直接放到 jwt 里。

@zhenjiachen jwt 的优势加个个性化需求了呗,楼主就是要登出,不然咋实现叻

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

grpc 可以用 basic auth 加盐的密码，放到 metadata ，类似于 http1 rest 请求的请求头

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

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

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

@wxf666 jwt 就是存客户端的，还存服务器 redis 不多此一举吗。重启下服务集体登出？

@dreamk #12

挪到，不是双重存储。。否则挪用公款，就是变出两份钱财的意思吗。。

redis 不是有 AOF 、RDB 机制吗？重启也不会丢数据呀。。

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

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

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

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

直接用 session 就好了

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

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

有 refresh 时间短点就搞定啊