落霞与孤鹜齐飞， JWT与Session两种验证机制的比较
大家好，这一期呢，我们来说一下网络程序开发中的验证的方式。常用的就是两种：jwt和session，现在来比较一下的这两种验证方式。
先来探讨一下这jwt的验证方式。这种方式就是在服务器端和客户端通过一个jwt token来保证通信的合法性。
在这个jwt token中你可以保存一些数据。要想看到这个token中存在哪些数据，你可以去这个jwt io网站上去查一下。里面的数据是成对的，有一个键值，有一个对应的值。
一个jwt token中，存在三个部分, 第1部分是头部, 用来存放算法和类型。第2部分是数据部分, 我们大部分时间会用到这一部分。第3部分是签名信息。
下面我们来看一下session的方式。 Session的关键就是一个section ID。 服务器端通过这个session ID来验证通讯的合法性。同时使用这个session ID来获取相应的信息。
这些信息可能是在内存中的数据信息, 也可能是在数据库表中，也有可能在其他的缓冲机制里面。
在大型项目中一般比较常用的就是像 redis 这样子的缓冲机制。在这个机制中会有一个redis的服务程序，有多个server，会有一个load balancer 负载均衡器, 这个负载均衡器作为与客户端进行交互的前沿。客户端跟负载均衡器之间通过session ID来进行交互。
现在来讨论一下这两种机制的好处和坏处。
jwt机制是无状态的。 在这种机制下，你不需要单独的存放任何与你的访问状态相关的数据。这些东西都在一个token里面。
这种机制的好处就是使 程序更加简单 。你不需要用额外的程序逻辑来管理通信状态。
坏处就是 数据是公开的 ，你只要拿到这个token，你就可以查到里面的数据。
另一个不好的地方是，如果token中你包含的数据太多，在通信过程中每次都要传送这些数据会 增加网络交互的负担 。
Jwt token, 你可以通过设置至一个超时值来让它 失效 。在它有效的这个时间里，除非你更改secret， 除此之外你是没有办法把它取消的。
Session机制是有状态的。 在通讯传输的过程中，你只需要传送一个 session ID 就可以了。与这个session相关的数据会在服务器端有一个备份。当然客户端也有一个备份, 因为你需要这部分数据去做一些前端的操作。
这种机制的好处就是安全。在传授的过程中，你只需要传输一个session ID, 不需要传送全部的数据信息。具体的数据，由你的请求类型来决定。
这种机制的坏处就是要额外去管理这部分通讯状态数据。对于我们程序来说，就要单独写相关的数据库表格来存放session部分，要写相关的程序来读取和更新这些数据。
在安全性上session有更好的优势。你可以删除服务器端的session数据。
具体到某个开发项目上这两种机制有优势也有劣势，不能一概而论，还是要具体问题具体分析。
作者简介：
山东人。
从事软件开发研究二十多年。
先后在如下地区工作：山东（青鸟华光），北京（北大方正，SDL Trados, O2Micro, Motorola ），德国斯图加特(Trados)，新加坡(ITE)，加拿大温哥华(Schneider Electric, Nokia Here, Western Digital, Microsoft, Aviso Wealth, MDA)，现居温哥华。
个人爱好：陪孩子玩耍学习，练拳，好好学习，天天向上。
专家领域：
安卓(Java, Kotlin ),iOS(Swift),
Angular( Typescript ,Javascript),
Asp .Net Core(C#),
Spring Boot(Java),
nodejs (Javascript),
Go(golang)
欢迎关注一起学习讨论，共同进步。
十年内计划写出超过三千六百篇文章，与超过三万名读者互动。
这些文章会在今日头条，知乎，简书，微博，微信公众平台，阿里大鱼号，Medium等各大平台同步上线，敬请期待关注，欢迎洽谈合作相关事宜。
