登陆验证发展史(cookie认证-＞session认证-＞token认证-＞JWT，单系统登陆-＞多系统单点登陆)

登陆验证发展史有两条主线。在服务部署方式层面，早期的Web服务系统简单一般都是单系统，登陆的话就登陆这一个系统就好了，随着系统复杂性越来越高，一个大的系统往往由很多子系统组成，用户使用这个大系统时不可能一个一个地单独去登陆每个小系统，理想的是只要登陆上了这个大系统或者其中的一个小系统，其它所有小系统都不需要再输密码什么的登陆了，直接访问，所以登陆验证就从单系统登陆演进为多系统的单点登陆。而在验证方式层面，经历了cookie认证->session认证->token认证->JWT的发展史。

以单系统登录举例，先从验证方式层面去看：

1.cookie验证

简单介绍一下cookie，cookie其实可以理解成存储在浏览器上的一种数据，里面的数据格式是key-value键值对，数据本质上是保存在终端某个本地文件夹内。cookie不能跨域，浏览器在访问某网站地址时，如果该网址的域有cookie保存在浏览器中，可以携带上对应cookie。谷歌浏览器可以在地址栏中输入chrome://settings/siteData?search=cookie来查看当前浏览器保存的所有cookie，可以看到每个cookie是哪个域下面的。cookie 长度不超过 4KB ，否则会被截掉。每个域名下的cookie数量是有限制的，不同的浏览器默认的数量限制可能不同，ie7之前是20个，ie7之后和Firefox一样都是50个，chrome 和 Safari 没有做硬性限制。

先贴一张cookie认证流程图：

cookie认证的登录超时一般是服务端设置cookie的有效时间。cookie认证特点最大的就是用户信息保存在浏览器，早期互联网环境还比较安全，后来大家发现请求一旦被拦截，被拿到cookie后用户信息就泄露了，然后开始给cookie中的用户信息加密，但这也是治标不治本的方法，只要用户信息是在浏览器，终究是不安全的，最大的问题还是用户信息保存在浏览器的话，服务端不好管理受限太多。而且虽然大部分浏览器都是默认开启cookie存储的，可是万一谁设置了一下不存储cookie呢，那岂不是登录不了系统了。还有就是浏览器一次请求会把对应域中的所有cookie全部带上，可以如果我只需要带有用户信息的cookie用来做验证呢，其他cookie岂不是白白增加了请求包大小，也是带宽的浪费。

可见cookie认证的缺点还是很多的，所以现在的Web应用一般都不用cookie认证了，后来出现了session认证。

2.session认证

session是存储在服务