这是我参与11月更文挑战的第15天，活动详情查看：2021最后一次更文挑战。
在上一篇文章里我们完成了基于JWT+RSA256的授权中心和鉴权工具类编写并验证了服务的可用性，本篇文章将对比基于Token与基于服务器的身份认证做个总结。
对比基于Token（即JWT）与基于服务器的身份认证
基于服务器的身份认证
1、最为传统的做法，客户端存储Cookie（一般是只存储Session id），服务器存储Session。
2、Session是每次用户认证通过以后，服务器为了记录用户的会话状态信息而创建一条记录保存用户信息，通常是存储在内存中，当然也可以存储在Redis中，随着认证通过的用户越来越多，服务器存储Session的开销就会越来越大，这也是Session的方式存储用户信息的最大问题。
3、由于客户端认证信息保存在Cookie中，在不同域名之前切换时，由于跨域问题的存在，请求可能会被禁止。
基于Token（即JWT）的身份认证
1、JWT与Session的相同点是它们都是存储用户信息的，但它的服务端可以不存储用户的身份信息，用于验证用户身份信息的JWT直接存储在客户端。
2、正由于JWT的方式将用户状态分散到了客户端中，所以可以明显减轻服务端的内存压力。服务器端直接使用算法去解析客户端携带的JWT，即可验证并得到用户的身份信息。
两者优缺点的对比
解析方法（解析规则）
JWT没有依赖，它使用算法和加解密规则直接解析得到用户信息。
而Session需要额外的数据映射，即数据存储来实现匹配，所以JWT更加简单高效。
管理方法
JWT在生成的时候可以填写过期时间，由于服务器端没有记录额外的信息，因此它只有过期时间的限制。
而Session数据保存在服务端，所以Session的方式有更强的可控性，毕竟服务端的数据可以随时由服务端去修改和更新。
跨平台
JWT其实就是一段经过加密的字符串，不存在跨平台的问题，可以任意传播。
Session由于需要客户端和服务端来共同控制完成，所以需要有统一的解析平台，比JWT的使用上要繁琐。
时效性
JWT的时效性是在生成的时候就指定好的，一旦生成，独立存在，后期很难做特殊控制。
Session由服务端存储和控制，所以时效性完全由服务端的逻辑说了算。
总结：各自都有各自的优缺点，都是登录、授权的解决方案。
