从用户登录开始说起，认证方式的变更
1 用户每次请求都带上账号密码
优点：通信简单，操作方便
缺点：账号密码需要一直存储在客户端，不安全。
2 使用Cookie
优点：对比1，客户端不需要记住密码，更安全；cookie是由浏览器自动发送，更方便
缺点：当前cookie标识简单，只有id和name，攻击者容易伪造cookie
3 使用升级版Cookie
其中 signature 为签名，使用服务端秘钥构造加密而成的
signature = sha256(
id=200&name=二毛&secret=ermaoxxxx
)
优点：对比2，服务端使用了秘钥加密了cookie标识，形成签名，更安全
缺点：客户端数据存太多了
4 使用Session
session的本质其实还是cookie，不同的是，session方式只返回一个复杂的ID到客户端，这个ID就是 SESSION_ID，对应服务端的key
优点：所有用户会话信息，都存储在服务端
缺点：非浏览器客户端使用Cookie不方便，如小程序、app。网络请求接口默认没有cookie机制
5 使用普通Token
既然网络请求接口方式，没有cookie机制，那么就自己维护该标识字段的请求：字段名字改为token，本质还是那个session。按照通用的约定，每次请求都会把token放在header中，供服务端校验
优点：解决了app网络请求没有cookie机制问题
缺点：在分布式场景下，如果请求打到其他机器，就会出现没有会话数据的问题，导致鉴权失败
6 使用redis统一存储token
所有token对应的kv值都放到redis中
缺点：如果redis失效了，那么会导致所有机器的认证服务不可用。
可能会有人说，那么可以使用多台redis集群，进行故障自动转移。这种确实不失为一种好方法，但是这样会带来运维成为的提升。
所以到这里，工程师们觉得还是将信息放在客户端中更好，从而让服务端不需要存储认证 key/token 对应的数据，从而减少运维成本。
从而有了我们下面的 jwt
7 使用JWT
全称是 json web token，是一种token构造标准，对比普通的token，jwt可以携带不敏感的数据，如 user_id，user_name 直接标识出用户
