- 主题:jwt相比普通token，优势在哪？
我反正一直没想明白用 jwt 是为什么。
一个猜想是 android/java 程序员的 http client 库没有管理 session 的能力，所以只好重新发明一个 sessionid 出来.
【 在 Millor (Millor) 的大作中提到: 】
: 我看也就是信息多一点，长一点
: 用户用起来也一样啊
--
FROM 111.142.201.*
session id 并不规定存在哪里。反正只要跟着请求一起发到服务器就行了。
【 在 eGust (十年) 的大作中提到: 】
: 我真佩服你们，这么简单的东西都搞不明白也能喷
: 你们的 session id 是啥，存在哪？
--
FROM 111.142.201.*
那总不能扔 WEB 请求里面占用宝贵的带宽。
【 在 eGust (十年) 的大作中提到: 】
: 你的服务器端要存一份不，需要占用硬盘或者内存不？
--
FROM 111.142.201.*
这件事我记得 hacker news 和 reddit 上面都讨论过。我反正也说不出啥新意。有兴趣的话自己去查查相当的讨论吧。
【 在 eGust (十年) 的大作中提到: 】
: 于是 load balance 后面 web service cluster 共用一个 session server/cluster 就不占用宝贵的带宽了？
--
FROM 111.142.201.*
占带宽是顺着你那句“存在哪里”说的。问题不在于这里。
我贴个链接吧：
https://news.ycombinator.com/item?id=16517412
还有一篇更完整的博客忘了关键词没找到。
【 在 eGust (十年) 的大作中提到: 】
: 要不你直接说说结论，还是说你的结论就是占带宽？我可没有别人随口那么一说就屁颠屁颠去找的习惯，更何况本来你的结论就一贯不靠谱
: 要是在乎真带宽还是上 graphql 吧，没必要的数据完全不发，http 本来 payload 就不低，根本不在乎多个几十上百个字节
--
FROM 111.142.201.*
所以说 jwt 更不安全。。
基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
它许诺的广告疗效还包括更容易横向扩展之类的。但我没看明白这个更容易是怎么个容易法，比用一行命令架构 redis 服务器还容易？
【 在 feed (鳄鱼) 的大作中提到: 】
: 针对于服务器可以自己验证签名，我倒有一点不解：
: jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
--
FROM 111.142.201.*
因为 sessionid 可以被吊销啊。比如检测到不正常的业务跳转就 invalidate admin sessionid. 或者运营人员禁用不正常用户写个脚本从 redis 里面清除它们的 sessionid. 你来说说用 jwt 这个需求怎么玩？
还有 csrf 是不是可以了解下。拿了 sessionid 也不一定能发 request 哦。
【 在 eGust (十年) 的大作中提到: 】
: 你在搞笑么……都拿到别人 session id 了，为啥不能直接发 request？
: 如果你说放 cookie 然后设 http only，那 jwt 也一样能放啊
: 拜托发帖的时候过一过大脑好么，真的是越来越觉得你小白了……
: ...................
--
FROM 111.142.201.*
redis/memcache 服务早就是非玩具 web 系统的标配了。哪来的多一个系统。
至于 redis 的 scale，用公有云是一个点击，用自建服务器，可能是两个点击吧。
【 在 eGust (十年) 的大作中提到: 】
: 你要是一个 jwt 里面不签失效时间那怪谁？admin 那么容易被攻击还一次签一年怪谁？
: 你用 redis 可以重启服务让所有 session 失效，我用 jwt 可以直接换一对密钥，有啥不能简单吊销的？
: jwt 不需要额外的系统。多一个系统部署上的复杂度就大幅增加，scale 的时候就更困难。这么简单的道理还需要解释？
: ...................
--
FROM 111.142.201.*
禁掉 sessionid 要求重新登录不是更好。你直接把 admin 禁用掉这算什么呢？
看你的意思，你是打算否认 csrf 攻击的存在吗？这是另外的话题了。有空再聊。
如果你不否认 crsf，那你仔细想一下，不维护 session 怎么在服务器保存 csrf token 用于验证客户端传过来的 token? jwt 能否实现这个目标。
【 在 eGust (十年) 的大作中提到: 】
: 不正常我把 admin 账户禁掉不行？为啥非得挑？
: jwt 一般也都是多组 key，直接废掉一组 key 行不？
: 你还是了解一下 csrf 怎么回事儿吧，我们 rails 打从第一个版本就带这东西了
: ...................
--
FROM 111.142.201.*
session 管理早就是各种 web 框架必备的，就是这么简单。
背后还有一系列的中间件依赖 session 处理各种认证、缓存。你用 jwt 就先把这些都废了重新写。
【 在 eGust (十年) 的大作中提到: 】
: 因为 session management 不光一个 redis 那么简单啊
: 人家 jwt 不需要多点击两下啊，为啥要多点两下？
--
FROM 111.142.201.*