- 主题:jwt相比普通token，优势在哪？
你的 header 指啥？csrf token？还是想说在 set cookie？是放 jwt 还是 session id？完全看不懂你在说啥，都是客户端 request 往 header 里放东西好给服务端做验证，服务器 header 放东西发客户端发是行为艺术么？
【 在 exbf (忘记我，向前进) 的大作中提到: 】
: 别的不评价，你这点纠正一下。确实不一样的。你签一个带随机token的header下发客户端没有鉴权的意义。因为它无法让不带这个随机token的header无效。集群无法判断是否存在这个token，除非有中央存储。
: 所以本质上jwt没有处理这个问题的能力，任何一个header只要泄露，在生命周期内基本是有完全的对应使用权的。
--
FROM 101.98.83.*
我发现几乎所有人都被你这个伪问题带沟里去了
检测到不正常业务都是直接封权限。挑 session 是什么鬼，难道是天朝人力太便宜了，养了一堆吃饱了没事儿干的运维？公司局域网里电脑中毒了难道不是是拔网线，处理完了再拿回来，而是进安全模式接着凑合用？
敏感业务需要输密码确认，如果还不够的话采用多步认证，比如密码器、u 盾之类的。靠运维给用户使用错误擦屁股，真不知道该评价是企业级应用还是开玩笑
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 因为 sessionid 可以被吊销啊。比如检测到不正常的业务跳转就 invalidate admin sessionid. 或者运营人员禁用不正常用户写个脚本从 redis 里面清除它们的 sessionid. 你来说说用 jwt 这个需求怎么玩？
: 还有 csrf 是不是可以了解下。拿了 sessionid 也不一定能发 request 哦。
--
FROM 101.98.83.*
最后我还想多说一点，跟技术本身无关。如果你带着偏见去看一门技术，就会连 csrf 怎么在 jwt 里面实现这种问题都能问的出来。不是针对某个人，老鱼别想太多。这是一个普遍现象，不光天朝，不光码农，全世界的人都一样。
随着年龄的增长，除了注意身体健康以外，我也是时刻提醒不要用抵触的心态去看新东西。这可能跟本科时的教育有关，当时老师的大意是，政客认为正确的东西，都是他大学时代的知识。引申出去，人到了一定年纪就不容易接受新知识了，这跟人们普遍的印象，年纪越大的人越不容易接受新事物是一样的。
前两天看到一个吐槽，我觉得道理是一样的，道格拉斯·亚当斯的科技三定律：
1）任何在我出生时已经有的科技都是稀松平常的世界本来秩序的一部分。
2）任何在我15-35岁之间诞生的科技都是将会改变世界的革命性产物。
3）任何在我35岁之后诞生的科技都是违反自然规律要遭天谴的。
刚刚特意搜了一下，的确能搜到英文版：
I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.
前一阵有新闻，吐槽现在的小孩子不知道磁带长什么样，不知道蜡烛长什么样，看到3寸盘完全不知道是啥。我完全不以为然，有什么好稀奇的。中学时课本上描述什么什么是纺锤形、梭形之类的，纺锤是什么鬼，梭子又是什么鬼，装备上之后攻击+5么？道理是一样的，凭什么现在的小孩子要知道他从小就没见过的东西，就因为在你小时候是稀松平常的？
【 在 eGust (十年) 的大作中提到: 】
: 啥意思，没看懂，但跟旧的 session id 要不要通过验证是等价的，session 啥样 jwt 就啥样
: 你要搞清楚，jwt 跟 session 在本质上是没差别的，都是证明是由服务器签发的 token。不同的是验证方式，session 放在内存/硬盘里，jwt 不存，通过私钥来验证签名是由服务器发出的。session 需要把跟 token 对应的信息都放在内存/硬盘里，jwt 把对应的信息放在签名里面了
: 其它的方面没有任何差别，任何你觉得需要放在服务器内存/硬盘里的东西，通过私钥签个名连带着关联的东西发出去就完了。甚至是不是 jwt 都不重要，只不过 jwt 标准化了，各个语言都有实现。
: ...................
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
要不您给我举个知名公司这么干的例子吧
没有困难制造困难也要上？
反正按照我们这的收费水平，我敢保证客户宁可重新登录一遍，也不会让从 session 里挑着删的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你这种讨论需求的方法我经常在 apple 版看到。
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
同样请求量 ssl + http header 能扛得住，再加上个几百个字节 hash 就挂了？
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 从你的补充看，jwt这个缺点大了啊。根本扛不住攻击（比如 大量invalid joken涌进来）
--
FROM 101.98.83.*
browser 自动管理 cookie 客户端不用管，设个 http only 又不用担心第三方 js 读，好处自然也是有的。所以这东西没什么绝对好或不好，最后选什么技术怎么用，都是各种利弊权衡之后的结果
【 在 menghan (skybluee) 的大作中提到: 】
: 没有哪种方案是绝对安全的，都需要 trade off
: csrf 只会发生在 web 场景，为什么呢，因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题，不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
: sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道"，而在于是否自签名。
: ...................
--
FROM 101.98.83.*
给你找台阶下……都不新鲜了还问 csrf 怎么生成这种不用动脑子的问题
【 在 hgoldfish (老鱼) 的大作中提到: 】
: jwt 这种也算新技术啊。。本青多年前就往 response 里面写 json 加密头了。每种技术都有优势和劣势，仔细分析才能应用到开发里面。你不要抓个新玩具都像拿到金羊毛一样高兴好不好。
: 要不我再放个大招吧。要说句不客气的话，放在整个软件开发领域，某个社区一票层出不穷的东东都不配叫”新技术“。
--
FROM 101.98.83.*
拜托人家说的是做登录认证用的
csrf 这东西弱的不要不要的，只防别的网站嵌个假链接让你点这么点儿事儿
只要你的接口遵守 restful，get 不改数据，这攻击就没效
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你还是仔细看一下前面的帖子吧。上面几个人在说 jwt 要做 csrf 得依赖 fallback 方案了。
: 顺便说一下想拿 jwt 来代替 session 还有一个问题。jwt 如果要主动失效旧的 token，那用户就不得不总得重新登录。这通常是反用户体验的——别跟我说什么不安全，这就是业务需求。而 session 方案，存个天长地久都没问题。
--
FROM 101.98.83.*
连这个东西的道理都不明白就在那强调重要性？要不给我们讲讲 py 的高大上实现？反正我们 rails 这边的实现弱的很，一半一半的内容，直接 xor 拼出来的后一半。
安全问题都是讲成本的，就像前面说的，你这么在意 csrf，jwt 不放 cookie 不就完了？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你这不就是 apple 版的一贯论调么——这个功能不重要。
--
FROM 101.98.83.*
安全问题从来就不是一个东西能解决所有的问题，你非把没多大关系的东西往这上面硬套，觉得有意思吗？github 你一个 form 发呆超过几分钟就保存不了，必须刷新。我们公司用的 google 账户，一个浏览器隔个三五天没用过，下次登录就得重新输密码。就算我天天上班用的电脑，时不时的也让我重新输入一次密码。
你觉得 csrf 异常重要所以还要单独 invalidate？我做个 jwt 设超时行不，5分钟没提交对不起保存不了。至于用户体验，你不是说 csrf 安全问题最重要么？
反正对我来说，不做 csrf 客户账户里面的东西别人动不了，get 看到的也是你自己的东西，屁大点儿事儿。钓鱼网站要是这种假链都做，那真的是活不了多久了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你这不就是 apple 版的一贯论调么——这个功能不重要。
--
FROM 101.98.83.*