一样啊，csrf 就是一个 random token 而已，我后端再生成一个 jwt 把 random token 和用于身份验证的 jwt 都签在一起不就完了？

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 拿到 sessionid 发动重放攻击跟 csrf 攻击是两件事。我原本就是分成两段话来讨论的。你为啥非常要混在一起呢？
: 至于 jwt 能不能做 csrf，要不你来说说后端不搞 session 的方案吧。
--
FROM 122.60.88.*

讨论一个技术，难道不能跟竞品技术比一下生态圈？session 管理的生态圈显然比 jwt 强大太多。

这也是我为什么在前面说，或许是 android/java 还有 nodejs 程序员的 http 库缺少 session 管理能力，所以比较热衷于这个技术。

【 在 eGust (十年) 的大作中提到: 】
: ……
: 这东西好不好用跟你已有系统或者现有系统用不用有啥关系？
: 你要是开发个百八十人用的东西，或者本来跑得好好的服务，还非得拿掉 session 重新用 jwt 那是自己作。这跟技术本身有啥关系？
: ...................
--
FROM 111.142.201.*

啥意思，没看懂，但跟旧的 session id 要不要通过验证是等价的，session 啥样 jwt 就啥样

你要搞清楚，jwt 跟 session 在本质上是没差别的，都是证明是由服务器签发的 token。不同的是验证方式，session 放在内存/硬盘里，jwt 不存，通过私钥来验证签名是由服务器发出的。session 需要把跟 token 对应的信息都放在内存/硬盘里，jwt 把对应的信息放在签名里面了。

其它的方面没有任何差别，任何你觉得需要放在服务器内存/硬盘里的东西，通过私钥签个名连带着关联的东西发出去就完了。甚至是不是 jwt 都不重要，只不过 jwt 标准化了，各个语言都有实现。

用 rails/django 这种最早一批的，肯定是默认自带 session 的。但是如今重前端的话，好多后端都是 micro service，裸 http 服务啥都不带，需要什么自己装 middleware。你可以选择 session manager，然后配置一下 redis 服务器之类，或者不折腾的话默认大概率存硬盘。同样你也可以选择装个 jwt 的中间件，然后生成几组 key，琢磨一下签出去的东西里面需要包含啥信息。这种情况下你觉得选 session 有任何优势么？

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 旧的 jwt 要不要通过验证？
--
FROM 122.60.88.*

谢谢，你这个答案终于回答到了我最想知道的地方了
能再详细的说一下吗？
如果是普通token的话，服务器要怎么验证呢？
谢谢谢谢

【 在 caogecym (操哥纯爷们) 的大作中提到: 】
: 节省存储空间，普通token如果没加密过的话，需要存在服务器里验证用。
--
FROM 101.38.23.*

只要有池子，就有中央存储，jwt最大的优势就淡化了。开个redis存session本身也不占内存
【 在 beep 的大作中提到: 】
: 讲得很好，赞
: 补充一点，jwt唯一的缺点我觉得就是无法即时invalid一个特定的token，如果业务需要，必须另作一个类似于session的小invalided joken池。因为不太可能短时间内遇到大量需要invalid的jwt，所以这个池子一般放单机内存就够了，不会使得架构更加复杂化。
: 另外值得提的区别就是，jwt服务端加解密稍微会多耗一点cpu，而session方案或者多耗点内存或者多耗点时间（硬盘io or redis 网络io）。
: ...................
--
FROM 117.136.38.*