我们在使用技术的时候首先应该明确这样一点：任何脱离了具体实际业务需求的选型都是扯淡。
比如说数据库，没人质疑MySQL在事务方面的特性强于Redis，也没人质疑Redis的QPS是MySQL的好几倍(当然要考虑具体配置)。这并不妨碍MySQL和Redis在江湖中的地位。
你说Redis快，真正用到实际业务上，真的可行吗？光是引入的复杂度就会让你抓耳挠腮了。
基于业务，合适能满足需求就好。
使用JWT更易于水平拓展
对于Cookie-Session方案来说，Cookie中会存储Session ID，而其它各种信息都存储在服务器中。如果把项目部署在多个服务器上，Session应该怎么办呢？可以Session复制、粘性Session、第三方存储Session。
而JWT只需要拿着这个Token去认证即可，JWT不需要存储在服务端中，不会占据服务器的资源。
使用JWT可以减少请求的数量
Token的话需要有一个认证服务来同一颁发令牌和校验令牌，这是因为Token本身不包含数据，它是进行用户认证会话的一个标识符。
JWT自包含数据和令牌，是无状态Session思想的拓展。
使用JWT只需要认证服务颁发JWT，再次访问的话通过一次验证即可获取请求，不需要再次调用认证服务验证。这样的话就减少了请求的数量，减少了认证服务的压力。
不过这也是存在问题的，安全性只能由JWT的算法来保证，适用于安全性不太敏感的场景。 这一点我是可以接受的。
多端适配方便
如今是移动互联网时代，但是各个端的应用都要使用同一个认证登录系统，因为如果每一个端都搞一套认证机制，成本太高，而且难以拓展。
而且进行拓展后要对每一个服务进行认证和鉴权。
使用token比使用session实现更加简单一些，更适用于多端应用登录
其它
开放平台理念
如今开放平台的理念开始走向主流，使用token是更为合适的，cookie以及session都无法很好的处理授权管理
