昨天开始着手用Koa重构Express的时候，在Github上面发现Koa组织里面关于jwt的star数比session更高，加上公司里面Java也是使用的JWT的认证方式，所以就很好奇的去查阅了一番关于它的知识，但是得到的结果并不满意，所谓的优点在我看来并没有比session更加强大，加上公司不大，大家了解不深，所以只能请教一下有深入了解的大神们。
有以下几点疑问
看了一些文章，对JWT本身有一些疑问，希望不吝赐教。
使用更简单
由于JWT本身需要你手动续时，而且续时是一件还挺麻烦的事情，而session是不需要的，那为什么会更简单？
更灵活
这一点的体现在哪里？能同时在不同的server下使用？但是我使用外接专门保存session的服务不也能达到同样的效果吗？
内置过期功能
这一点session是自带的啊，所以好在哪？
实在是好奇应用场景
- 有人说纯API的服务好用？但是也没说清楚好用在哪？
- 有人说它更加的安全，存储在`client`下面真的更加安全吗？
- 有人说它更容易扩展，很好奇什么业务下需要扩展什么东西？
问题略多，还请见谅，因为实在是有太多疑问了，google了一番心中的困惑确实也没有解开很多，望见谅。
简单说2点吧
- jwt一般用于api鉴权，是无状态的，鉴权成功后，token由client持有，每次api请求带上token即可。
- session是http会话，是有状态的，一般类似于tomcat的ttl是半小时，以前用户登录后下的订单类的都是走session的，现在session也持久化了，用处不大
@hewentaowx 这些东东我是看过了，也明白原理是什么，我就是想不通它到底优秀在哪，为什么别人说它差…
https://scotch.io/bar-talk/why-jwts-suck-as-session-tokens
https://www.zcfy.cc/article/stop-using-jwt-for-sessions-joepie91s-ramblings
有利有弊：
- 以前分布式的session都是通过保证储存位置一致 或者 session共享复制 或者 通过会话保持实现
- 会话保持的话，如果对应的那台机挂了，这个用户就一直无法获取正常的服务
- session共享复制的话，效率不会太高，高吞吐效果差
- 储存位置一致比如nfs或直接使用redis或memcache，和上面有点像，每一次都要去session储存服务中心去取一次或多次，多N次通信交互
- 使用jwt的话，避免了上面3个问题
@zy445566 谢谢啦，对应的几点疑问，还希望能够告知
1. 会话如果不保持，服务端对客户端的控制权就降低了，相当于客户端拿到token之后就能为所欲为，这个怎么控制呢？session可以清除，在jwt中是否需要实现这种机制，如果不实现是否会存在我之前的问题？
2. 共享机制是jwt的一大优点
3. 如果使用 jwt 就需要使用频繁的手动续时操作，这个与session频繁的取差别很大吗？还是说，续时操作能有更高级的做法。@mintsweet 说一点我遇到的吧 做分布式的时候用session难免要做数据持久化吧走数据库查询吧 用jwt至少避免了这个问题。 而且我知道如果在没有完全知晓为什么的时候，大部分人说它好那一定有它好的道理。其实很简单 你对比一下session可以使用的场景jwt是否适用 jwt使用的场景session是否适用 对比一下优劣度不就好了 ，没有绝对好的东西只是相对好就可以了
@mintsweet 第一 客户端拿到token但是解密加密都在服务端如果客户端没有密钥有token也没有什么用，而且后端可以设定密钥不定期更改 第二 jwt的续时问题 你写一个公共方法 在需要登录之后的操作每次调用接口可以用旧token换新token 如果长时间没有调用接口到了token过期之间自然会强制登录 虽然和session频繁取差不多 但是看广度、优劣度选一个就好了
- 这是两个问题
- 会话保持不是你想的这样，原理是通过cookie的中session_key值hash到固定的某台机器上,保证这个用户每次访问都会访问到同一台机器，这样session数据就不用共享了，至少我们这边叫这个会话保持，我想你可能理解错了。
- 很简单全部清除的方式就是换私钥不就好了，你要清除某个人的话，jwt数据里面存用户类型和要过期的时间不就好了，判断该丢弃就丢弃
- 我说共享机制是原来session的缺点，没说是jwt优点
- jwt解密完数据就在那台机器的内存里面了，不需要去redis读数据，省网络时间。如果是原始的频繁读本地的话，文件是有锁的。
我个人使用jwt会把jwt储存在redis，每个用户登录和登出都去redis检查用户的token列表中的jwt是否过期，过期的去掉，收到的token不仅要检查有效性还要去列表检查，不存在也视为无效，用户登出也要请求，服务端把当前token去除，这样实现jwt也有状态。
@poorEnMe 是类似，但是session是由浏览器cookie决定的，遵循一些默认的规则，而jwt是应用程序自己控制的，对于分离api模式的开发来说，我不许需要太纠结cookie等这些东西，我觉得是抛弃了cookie这种规则而自己定了轮子，我的理解是这样。
jwt问题是如果涉及到用户权限修改或者登出都不适合，数据时效性差。如果你存状态那就又和session相识了。 感觉小项目不涉及用户权限，单点登录之类的都可以用jwt。相反还是老实用session
以我的经验来看，jwt的优点在于其无状态，服务端对于签发出去的jwt无需保存，解析完就能用。解决了session的从哪读，怎么读的蛋疼问题。 但是同样，它的缺点也是无状态。对于签发出去的jwt，服务端没有很好的办法管理他，不像session只要删了就搞定了
给楼主点个赞，会想敢问，不知道楼主有没有被说服，但我看完上面的讨论是没有被说服的。 jwt不用在服务器存储“session”，这最多算一个特点罢了，不知道怎么就变成了优势… 有谁把session放Redis里面，然后由于应用分布式部署然后单点Redis扛不住？扛不住不是还有集群么，关键是有多少公司能遇到这样的并发量？
jwt的优势用session也没问题，jwt的缺陷用session依然可行。比如，token强制失效如果只能用存储session的方式来解决，那声称jwt比session更厉害不就是个笑话了吗？
来自✨ Node.js开源项目精选✨
@Shasharoman 没错，而且token因为基于算法。所以如果要实现强制失效，最后还得存数据库。真是个笑话。。。也不知道鼓吹jwt优越的人咋想的，完全不考虑实际情况，漏洞那么明显。
来自✨ Node.js开源项目精选✨
@vendar 浏览器cookie不跨域，token可以跨域，通过api集合访问多服务的情景下，用基于cookie的seesion是很麻烦的，但是基于token的seesion就可以很方便实现，其实我觉得标题就不太准确，seesion是一种概念，jwt是其中一种实现模式，个人觉得都是看场景的，对于前后端分离和微服务架构来说，使用基于token的认证模式，不需要考虑和配置太多事情（cors跨域资源共享机制、jsonp等等东西），jwt也可以有状态，只不过这样做就和基于cookie 的相同，但不是用cookie机制，而是客户端自身维护的token，主要的区别就在这，对于什么jwt不存在服务端什么的，这都是可以自定义的，根本没有什么哪个比哪个好，也不存在什么漏不漏洞，只是功能如此。
