每月一争, 为什么 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 ~ 黑名单数量

[SethShi]

还有 access_token 一个就够了, 为什么还要有 refresh_token, 除了官方说的安全之外, 就是可以作为两个时间点去使用.
access_token 每次都要校验, 可以简单的校验, refresh_token 使用的频次比较少, 这时候可以做更完整的校验.

[LeegoYih]

用了 JWT 还要存 token 到服务端，每次还要查版本号和黑名单，不是脱裤子放屁吗？
用户权限之类的更新了怎么办？难道让用户退出重新登录一遍吗？
查一次缓存就能解决的事情，不要太小看 Redis 的性能了。

而且 JWT 不是 100%安全的： https://github.com/yihleego/jwtcrack

[oldshensheep]

你这个都依赖 **分钟级别过期 access_token**

你加个 token_version 那每次刷新 jwt 就要查询数据库，而且你刷新的非常频繁，这不又和原来一样
同样的还有检查 device_id 要查询数据库

[giter]

我选择把 accessToken 与 refreshToken 存在 localStorage 中。既然要 JWT ，那就贯彻到底，给服务端彻底减负。

[nomagick]

jwt 真正的用途在于验证其他站点的用户和 token ，而不是自己站点的。
不要为了用而用。

[ztxcccc]

别查库了谢谢

[amlee]

jwt 的设计初衷就是要无状态，如果你的需求必须要求有状态，那么 jwt 的设计不适合你，为什么不用现成的 session 方案？
这本质上是一个需求和设计是否匹配的问题，搞清问题本质，跟技术优劣，或者说能否给技术打补丁以满足需求没关系。
板砖和锤子都能敲钉子，你非要说我能打磨一个完美的板砖去敲钉子，那我只能说脑子有包

[gogola]

@LeegoYih #2
暴力破解这玩意，不好说。

[CodeCodeStudy]

token 存 redis 不就完事了？

[emric]

我这边用 last_login ，日期不相同就拒绝。
感觉你说的大部分问题，都是修改以下 last_login 就行。

[SethShi]

@LeegoYih 我就问一下, 你使用 token 权限更新了怎么办? 这个和 jwt 没关系. 你权限更新其它方式该怎么做就怎么做. 不是我小看, 而是如果还不消耗存储, 不消耗 io 的方式为什么不讨论呢?

@oldshensheep token 的方式, 按用户级别来说, 每次请求来都查 redis, 并且 jwt 包含千万级别的用户数据, 而刷新的时候查询, 减少了 90% 的请求, 并且 redis 的存储只用非常少
@giter 没错了, 那肯定都要存客户端的, 和我说的没区别
@nomagick 你在哪看的定义? 你说的是 oauth2 吧
@ztxcccc 举个栗子
@amlee 又来一个不看解决方案, 上来就说不查库的

[SethShi]

@CodeCodeStudy 话说不看场景直接就存?
@emric 原理方案差不多的, 总是有些人在说为什么不存 redis 呢. 所以要讲这个东西.

[ellermister]

那每个 jwt 请求到服务端不都是要查一下有没有在 redis 黑名单列表里，千万级的用户也是千万级的查询啊，jwt 只是把 redis 存储大小改了，没改变查询次数。
@seth19960929

[SethShi]

@LeegoYih 我看了两眼你这个代码, 上来来个碰撞代码就说不安全, 能拿出具体的文献出来吗.
按你这样子说, 世界上没有安全的加密, 我只要写一个碰撞代码, 它们安全只是我现在没有碰撞到, 不代表我做不到.

[SethShi]

@ellermister 嗯嗯, 这是一个讨论帖子.
两种方案:
1. 只在刷新 token 的时候才查询是否在黑名单, 请求可以降低非常多, 有个问题就是会有延迟, 比如 5 分钟刷新一次 token, 那么就会加入后有 5 分钟延迟. 如果是部分场景完全可以用这种(只要 app 左右逻辑处理, 能及时失效, 如果有人窃取了 token, 那么它也只能使用 5 分钟, 到期了刷新就会得知被加入黑名单)
2. 大小还是差别很多的. 往 redis 里存 32 位字符串 key 1000w 个看看. 我等会给一个答案

[LeegoYih]

#14
确实我代码写的不咋地，想看看你写的。

参考文献：
https://insomniasec.com/blog/auth0-jwt-validation-bypass
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
https://evertpot.com/jwt-is-a-bad-default/
<amp-youtube data-videoid="GdJ0wFi1Jyo" layout="responsive" width="480" height="270"></amp-youtube>https://news.ycombinator.com/item?id=13866883
https://x-team.com/blog/my-experience-with-json-web-tokens/
http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

[8355]

只用 jwt 没有防御措施绝对是错误的行为

单 ip 连续请求错误 token 值为不可信行为，这是风控策略应该做的事
在敏感操作必要时进行密码检查

仅传入 token 就给予最大用户操作权限本身就不合理

[shakaraka]

你说得对

[Masoud2023]

你文中的黑名单和单台设备下线，归根结底都是要去查库，那用 jwt 和不用 jwt 做 sessionid 有什么区别么

[SethShi]

@LeegoYih
只要循环结束, 我一样能破解呀.

for ($i = 1; $i < pow(32, 16); $i++) {
$key = genKey($i);
$result = openssl_decrypt(hex2bin('1fbf2605f954fad3ba18115000735aee'), 'aes-128-cbc', $key, 1, '0000000000000000');
}