- 主题:jwt相比普通token，优势在哪？
本质区别是
cookie 对应于服务器上的 session。cookie 本质上是不受信任的，所以要通过 cookie['sessionid'] 到服务器上的 session store 里找 session，从而拿到用户信息。
需要全局的 session store，规模大了需要分布式存储，一致性、可用性代价高
jwt 是自带 sign key 的，sign key 是服务端签发的。服务端可以非常简单地 verify sign，不依赖什么 store。
【 在 Millor (Millor) 的大作中提到: 】
: 我看也就是信息多一点，长一点
: 用户用起来也一样啊
--
FROM 111.193.254.*
当我们讨论 jwt/cookie 的区别时，我们不是在说这些。因为 jwt 常常基于 cookie
我们讨论的其实是 jwt/cookie 在认证上的策略有什么区别。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 不准确吧，不能把jwt和cookie对立对比。jwt也可以放cookie里，自己设计的cookie token也可以加上密钥签名的部分。
--
FROM 120.52.147.*
破不了。所以一般 jwt 自带有效期比较短
【 在 feed (鳄鱼) 的大作中提到: 】
: 针对于服务器可以自己验证签名，我倒有一点不解：
: jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
--
FROM 111.193.254.*
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 标 题: Re: jwt相比普通token，优势在哪？
: 发信站: 水木社区 (Thu Mar 14 17:05:34 2019), 站内
:
: 所以说 jwt 更不安全。。
没有哪种方案是绝对安全的，都需要 trade off
:
: 基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
csrf 只会发生在 web 场景，为什么呢，因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题，不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道"，而在于是否自签名。
如果不自签名，则需要服务端引用大规模分布式存储来排查，如果自签名，则不需要分布式存储
:
: jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
jwt 当然也可以吊销，办法是引入一个专门用于保存吊销数据的分布式存储。
虽然架构 fallback 到旧方案，但是规模可能小很多
:
: 它许诺的广告疗效还包括更容易横向扩展之类的。但我没看明白这个更容易是怎么个容易法，比用一行命令架构 redis 服务器还容易？
session 数据是不建议存放在 redis 里的，至于 redis 为什么不适合干这个事情，有些跑题了，可以多了解服务端开发的架构
:
: 【 在 feed (鳄鱼) 的大作中提到: 】
: : 针对于服务器可以自己验证签名，我倒有一点不解：
: : jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
:
:
: --
: 灭绝人性啊
:
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 111.142.201.*]
--
FROM 111.193.254.*
我明白你想知道 jwt 到底比 session(id) 方案好在哪儿，其实我已经说了，可以通过算签名比对的方式不依赖大规模分布式存储。
但是你觉得这有什么了不起，对不对，session 的方案已经很全很完善了，依赖一个存储有啥问题，更何况说不定可以使用 redis，redis 又快又方便，为什么要开发另一类东西。
我想说，你对大规模，对什么叫分布式存储，一无所知啊
我觉得再说就得重开一个题目，作为对一个合格开发者的尊重，我也不适合在这儿讲课，又不是老师，可以自己去查查，开发和维护分布式存储有什么难的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不是说 session 能避免 csrf，我是说在 sessionid 技术下很容易解决。而在 jwt，还得引入 fallback 方案。额外的开发是小事，但我估计很多程序员估计会直接省掉吧。
: 要我看，jwt 需要在非常大规模的 web 开发，以至于 session 存储的开销成为重大问题的情况下才能应用。现在被误用得太厉害了。
: session 不要存储在 redis 里面这一条倒是很有意思。可以说说。
: ...................
--
FROM 111.193.254.*