- 主题:jwt相比普通token，优势在哪？
1. 明文编码、加密各存一份，服务端可以选择不解密验证，直接用，也可以选择解密验证再用（后者可以防简单的身份冒用）
2. 服务端不需要再维护session池，有利于服务端水平扩展
【 在 Millor (Millor) 的大作中提到: 】
: 我看也就是信息多一点，长一点
: 用户用起来也一样啊
--
FROM 223.72.67.*
不准确吧，不能把jwt和cookie对立对比。jwt也可以放cookie里，自己设计的cookie token也可以加上密钥签名的部分。
【 在 menghan (skybluee) 的大作中提到: 】
: 本质区别是
: cookie 对应于服务器上的 session。cookie 本质上是不受信任的，所以要通过 cookie['sessionid'] 到服务器上的 session store 里找 session，从而拿到用户信息。
: 需要全局的 session store，规模大了需要分布式存储，一致性、可用性代价高
: ...................
--
FROM 120.244.120.*
讲得很好，赞
补充一点，jwt唯一的缺点我觉得就是无法即时invalid一个特定的token，如果业务需要，必须另作一个类似于session的小invalided joken池。因为不太可能短时间内遇到大量需要invalid的jwt，所以这个池子一般放单机内存就够了，不会使得架构更加复杂化。
另外值得提的区别就是，jwt服务端加解密稍微会多耗一点cpu，而session方案或者多耗点内存或者多耗点时间（硬盘io or redis 网络io）。
【 在 eGust (十年) 的大作中提到: 】
: 啥意思，没看懂，但跟旧的 session id 要不要通过验证是等价的，session 啥样 jwt 就啥样
: 你要搞清楚，jwt 跟 session 在本质上是没差别的，都是证明是由服务器签发的 token。不同的是验证方式，session 放在内存/硬盘里，jwt 不存，通过私钥来验证签名是由服务器发出的。session 需要把跟 token 对应的信息都放在内存/硬盘里，jwt 把对应的信息放在签名里面了
: 其它的方面没有任何差别，任何你觉得需要放在服务器内存/硬盘里的东西，通过私钥签个名连带着关联的东西发出去就完了。甚至是不是 jwt 都不重要，只不过 jwt 标准化了，各个语言都有实现。
: ...................
--
FROM 120.244.120.*
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你还是仔细看一下前面的帖子吧。上面几个人在说 jwt 要做 csrf 得依赖 fallback 方案了。
: 顺便说一下想拿 jwt 来代替 session 还有一个问题。jwt 如果要主动失效旧的 token，那用户就不得不总得重新登录。这通常是反用户体验的——别跟我说什么不安全，这就是业务需求。而 session 方案，存个天长地久都没问题。
这个没看懂啊，你可能不太了解jwt的常见用法，一般jwt里面的数据除了等价于sessionid的那个id，还会附加issue time和expiration time等，你要是业务上需要三年有效的token，签jwt的时候打个三年的有效期就好了
--
FROM 120.244.120.*
jwt一般也不放cookie吧，我见过的项目一般都是走http header，这样的方案在native app端和web端通用，后端不需要分两种情况处理。web前端持久化大多数也是放localstorage。cookie这种远古浏览器黑盒子，黑魔法太多，应用层不能主动控制细节，不同浏览器行为也有细微区别，安全上也有些并非总所周知的坑。
【 在 eGust (十年) 的大作中提到: 】
: 连这个东西的道理都不明白就在那强调重要性？要不给我们讲讲 py 的高大上实现？反正我们 rails 这边的实现弱的很，一半一半的内容，直接 xor 拼出来的后一半。
: 安全问题都是讲成本的，就像前面说的，你这么在意 csrf，jwt 不放 cookie 不就完了？
--
FROM 120.244.120.*
而且jwt也可以做到类似seesion的自动延期，比如你前端对鼠标click事件或者ajax请求事件做个throttle，throttle里面去申请更新一个jwt就好
【 在 Insua (Xeneizes) 的大作中提到: 】
: 谢谢，你说的对，应该把表单的内容都缓存一下
--
FROM 223.72.67.*