节省存储空间，普通token如果没加密过的话，需要存在服务器里验证用。
--
FROM 166.216.157.*

当我们讨论 jwt/cookie 的区别时，我们不是在说这些。因为 jwt 常常基于 cookie
我们讨论的其实是 jwt/cookie 在认证上的策略有什么区别。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 不准确吧，不能把jwt和cookie对立对比。jwt也可以放cookie里，自己设计的cookie token也可以加上密钥签名的部分。
--
FROM 120.52.147.*

针对于服务器可以自己验证签名，我倒有一点不解：
jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？


【 在 menghan (skybluee) 的大作中提到: 】
: 本质区别是
: cookie 对应于服务器上的 session。cookie 本质上是不受信任的，所以要通过 cookie['sessionid'] 到服务器上的 session store 里找 session，从而拿到用户信息。
: 需要全局的 session store，规模大了需要分布式存储，一致性、可用性代价高
: ...................
--
FROM 114.255.24.*

所以说 jwt 更不安全。。

基于 sessionid 的认证可以搞 csrf，而 jwt 不行。

jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。

它许诺的广告疗效还包括更容易横向扩展之类的。但我没看明白这个更容易是怎么个容易法，比用一行命令架构 redis 服务器还容易？

【 在 feed (鳄鱼) 的大作中提到: 】
: 针对于服务器可以自己验证签名，我倒有一点不解：
: jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
--
FROM 111.142.201.*

你在搞笑么……都拿到别人 session id 了，为啥不能直接发 request？

如果你说放 cookie 然后设 http only，那 jwt 也一样能放啊

拜托发帖的时候过一过大脑好么，真的是越来越觉得你小白了……

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 所以说 jwt 更不安全。。
: 基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
: jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
: ...................
--
FROM 122.60.88.*