每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

[SethShi]

JWT 的基本就不再过多阐述

思考的问题前提: 比如我们面对一个千万级用户的系统. * 客户端需要和服务端交互, 假设 50% 的接口需要校验 * 10% 的接口需要获取个人信息

• 如果是 token 那么代表着 50% 的流量都需要去查 db(任何 db 都可以)
• 如果用 jwt 我可以减少到 10%, 甚至更少

---

至于常见的 JWT 诟病解决方案

• 两个小时没操作自动掉线
  • 分钟级别过期 access_token, 2h 过期 refresh_token, 完全可以做到
• 黑名单, 强制下线功能
  • 分钟即被过期 access_token, token 里包含信息 {uid: xxxx, token_version: xxx}
  • 修改密码, 或者强制下线, 修改 db 里的 token_version
  • 当要刷新 token 的时候, 校验客户端 token 里的 token_version 是否等于 db 里的 token_version, 不等于强制下线.(是在每一次去校验还是在刷新 token 的时候去校验都可以)
• 单台设备下线, 这个我认为是业务的逻辑
  • 分钟即被过期 access_token, token 里包含信息 {uid: xxxx, device_id: xxx}
  • 当要刷新 token 的时候, 校验客户端黑名单 db 里是否包含这个 device_id

为什么要用 JWT ?

• 使用 token 会有千万级用户请求 * (存 token + 查 token redis)... 用户名,xxx 存储,

下线, 黑名单为什么不直接存储 token ?

• token 可能千万级别, 但是黑名单保守估计不会超过 1w, 并且我可以把黑名单 token 有效期设置成 refres_token 的有效期(极大的减少了黑名单 token 的数量), 这样子当黑名单过期了, 那么 refresh_token 也不能再使用了(如果去颁发, 在黑名单中也颁发不了)
• 如果一个用户可能登录 5 个设备, 那么存储的 token 量就是 1000w * 5, 而 jwt 就是 0 ~ 黑名单数量

[akira]

那个，你们家用户都是千万级的了么。。。

[GeruzoniAnsasu]

看了半天在吵什么……

> 普通的 token 无任何有效信息, 只是一个唯一值, JWT 的话可以通过 秘钥 从 token 里解析出 uid 之类的, 这样子有些场景只有 uid 就不用查数据库
原来还就是车轱辘话翻来覆去讲，说到底 OP 发现的「优势」也就是 jwt 带信息，随机 token 不带信息而已，这不就是废话……


> 至于常见的 JWT 诟病解决方案
OP 的这段发散了这么多，加上他楼下的回复，其实就一句话： 退化成普通 session / token 方案


> 为什么要用 JWT ?
> - 使用 token 会有千万级用户请求 * (存 token + 查 token redis)... 用户名,xxx 存储,
文不达意。 根本原因其实就是 jwt 携带的信息可以短路一部分查库判断而已




我来替 OP 总结一下他的看法：
1. 在最坏场景下，jwt 退化成普通 session/token 方案，此时主要缺陷是 jwt 数据量引入的内存浪费，但即使在极大并发量条件下 redis 的性能也完全够用，所以可以忽略不计
2. 在典型场景下，jwt 自带 session/token 方案需要查库才能获得的关联信息，如用户 id 等，在这些场合下能节省大量数据库连接资源


所以这不就是什么「初识」、「入门」文章里就提到的东西么……

[hyperbin]

@LeegoYih If you are very lucky or have a huge computing power ，相当于说国库不安全，如果你有灭国级的实力的话

[SethShi]

@daimubai 查一次和一万次能一样吗？这样子说的话，干嘛架构这么多，干嘛用这么多缓存，直接查数据库了
@GeruzoniAnsasu 一直强调更多的怎么去解决 jwt 的问题，我后面说的这么多黑名单，刷新的机智话说都无视了吗
@akira 这是一个讨论贴，可以直接 block

[QlanQ]

@seth19960929
嗯嗯, token 也是一种方式, 就是随机字符串存到 redis 映射出 uid, 现在说这种存 redis 和 jwt 哪种更好.

本质都是一个字符串是吧，jwt 、token 傻傻分不清

[SethShi]

@QlanQ 对, json web token 从名字看出来它也是一种 token

[daimubai]

@seth19960929 #44 查一万次是怎么得来的？

[daimubai]

@GeruzoniAnsasu 他都不知道自己在说些什么

[chendy]

JWT 适合自家服务之间通信，网关授权之后带上 JWT 请求后续服务，后续服务不需要再查用户权限之类的东西，降低用户中心服务的负载
客户端还是适合最朴素的 token 模式（ cookie 里的 sessionid 其实也是一种 token ）

[SethShi]

@daimubai 1000w 用户都请求有没有 1000w 次, 什么怎么得来的.
@chendy 就网上的帖子来看, JWT 很多时候还是给客户端用的, 而不是你说的内部服务

[v2Geeker]

我们公司是全线用的 OIDC 那一套，当然也就用了 JWT 。这套像介于传统 Session 和 无状态 JWT 之间，服务端和客户端双赢。

[chenlins]

@chendy 赞同，我觉得这是 JWT 的最佳实践

[8rmEHZ8WhVHVOb0E]

你说的方案并没有节省 Redis 查询次数，只省略了 redis 内存而已，但是:
Jwt 方案 token 长度往往有数百个字符串，并且根据 Payload 内容的增多而变的更长，每次请求都会把这些东西带上。
而类 session 模型的 token ，token 字符串长度往往控制在几十个字符串长度。

假设每个平均每个 jwt token 长度 250 个字符串，而 session 模式的 token 长度 50 个字符串，那么每个请求就多了 200 个字符串，如果你的网站每秒 1 万 QPS ，你的服务器带宽峰值大约会提高 40Mb

40Mb 带宽明显比几 G redis 内存要贵鸭

[SethShi]

@xiaomada 服务器的带宽一般只计传输给客户端的, 不计客户端上传

[SethShi]

@xiaomada 请看原文, 只有当 refresh 的时候才去查询 redis. 至少减少 99% 的查询 redis 次数.