别的不评价，你这点纠正一下。确实不一样的。你签一个带随机token的header下发客户端没有鉴权的意义。因为它无法让不带这个随机token的header无效。集群无法判断是否存在这个token，除非有中央存储。
所以本质上jwt没有处理这个问题的能力，任何一个header只要泄露，在生命周期内基本是有完全的对应使用权的。
【 在 eGust 的大作中提到: 】
: 啥意思，没看懂，但跟旧的 session id 要不要通过验证是等价的，session 啥样 jwt 就啥样
: 你要搞清楚，jwt 跟 session 在本质上是没差别的，都是证明是由服务器签发的 token。不同的是验证方式，session 放在内存/硬盘里，jwt 不存，通过私钥来验证签名是由服务器发出的。session 需要把跟 token 对应的信息都放在内存/硬盘里，jwt 把对应的信息放在签名里面了。
: 其它的方面没有任何差别，任何你觉得需要放在服务器内存/硬盘里的东西，通过私钥签个名连带着关联的东西发出去就完了。甚至是不是 jwt 都不重要，只不过 jwt 标准化了，各个语言都有实现。
: ...................
--
FROM 117.136.38.*

是啊，如果用个redis这么难，那前面有人为了解决invalid token问题连消息中间件都用上了，还觉得这个代价轻，用的很普遍。我就呵呵了，会比redis更普遍吗。想起一个成语，叫削足适履。不说jwt有没有用，但如果你确实需要invalid token而把消息中间件加上的话，还是老实用redis吧。
【 在 haili 的大作中提到: 】
: 说起来4年前用play的时候，就见过它们鼓吹的stateless，确实也相对方便一点，逻辑也是secKey hash签名加上数据存客户端传递。JWT算是一个更加公开和规范的版本。
: 业务要求无需登录，APP级的最好直接上指纹等原生安全方案存登录信息，嵌入微信/支付宝就依赖平台的oauth能力按说也够了。
: 不过前面有人说redis不适合session或者是分布式redis很难？不知道何解？
: ...................
--
FROM 223.104.3.*