Session、Token和Jwt的区别和优劣

（1）session
1、用户向服务器发送用户名和密码。
2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3、服务器向用户返回一个 session_id，写入用户的 Cookie。
4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

*通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大

• 分布式X 用户认证之后，服务端做认证记录，如果认证的记录被保存在当前服务器内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力
  *CSRF

（2）token
将各个应用程序与内存数据库redis相连，对登录成功的用户信息进行一定的算法加密，
生成的ID被称为token，将token还有用户的信息存入redis；等用户再次发起请求的时候，
将token还有请求数据一并发送给服务器，服务端验证token是否存在redis中，
如果存在，表示验证通过，如果不存在，告诉浏览器跳转到登录页面，流程结束。
token方案保证了服务的无状态，所有的信息都是存在分布式缓存中。基于分布式存储，这样可以水平扩展来支持高并发。

（3）jwt

json格式的通用性，所以JWT可以跨语言支持，比如Java、JavaScript、PHP、Node等等。
可以利用Payload存储一些非敏感的信息。
便于传输，JWT结构简单，字节占用小。
不需要在服务端保存会话信息，易于应用的扩展

*如果用户信息发生更新了，只能等旧的 jwt 过期后重新签发新的 jwt。
*安全性没法保证，所以 jwt 里不能存储敏感数据。因为 jwt 的 payload 并没有加密，只是用 Base64 编码而已。
续签问题。当签发的 jwt 保存在客户端，客户端一直在操作页面，按道理应该一直为客户端续长有效时间，否则当 jwt有效期到了就会导致用户需要重新登录。那么怎么为 jwt 续签呢？
最简单粗暴就是每次签发新的 jwt，但是由于过于暴力，会影响性能。如果要优雅一点，又要引入 Redis 解决

1. 去中心化的JWT token
   优点：
   1. 去中心化，便于分布式系统使用
   2. 基本信息可以直接放在token中。 username，nickname，role
   3. 功能权限较少的话，可以直接放在token中。用bit位表示用户所具有的功能权限
   缺点：服务端不能主动让token失效

   2. 中心化的 redis token / memory session等
      优点：服务端可以主动让token失效
      缺点：
      1. 依赖内存或redis存储。
      2. 分布式系统的话，需要redis查询/接口调用增加系统复杂性。