背景
内容是极客时间-徐长龙老师的高并发系统实战课的个人学习笔记，欢迎大家学习！https://time.geekbang.org/column/article/596644
使用Session方式实现用户的用户鉴权
优点
信息都在服务端储存，对客户端不暴露任何用户敏感的数据信息
缺点
- Session Cache空间会变得很大
- Session Cache和各个子系统的耦合度极高，全站的请求都会对这个缓存至少访问一次
使用jwt登陆和token校验
用户登陆之后会将用户信息放到一个加密签名的token中，每次请求都把这个串放到header或者cookie内带到服务端。服务端解开这个token即可获取用户的信息
token=header+payload+signature
header: 保存加密算法类型
payload: 自定义的内容(用户昵称，uid，过期时间等等)
signature: 防篡改签名
解密
token，第一段和第二段通过base64编码
验证是否过期，其中的过期时间和本地时间对比一下即可
流程图
缺点
如果用户被拉黑了，客户端最快也要在token过期之后才能推出登陆，时效性较低
token的更换和离线
一般使用两种token=refresh_token+access_token
refresh_token用于更换access_token，有效期是30天；
access_token用于保存当前用户信息和权限信息，每隔15分钟更换一次
如果用户中心请求失败，APP处于离线状态，只要检测到本地的refresh_token没有过期，系统仍可以继续工作，直到refresh_token过期为止。
流程图
总结
个人理解：
其实Session和token的方式完全可以结合起来用
- Session 耦合性高，实时性高
- Token 耦合性不高，实时性低
问题
使用base64加密是不是不太安全？这样不是很容易知道你用什么加密算法了
这个算法重点并不是这个payload区，payload这里只是附带的数据，只是为了方便业务使用，事实上这个核心在于签名和过期时间，由于密钥是只有服务端有，所以签名是不能伪造的，如果到子业务这里验证签名是正确的密钥加密的，那么代表token的payload的内容肯定是服务器发放的，传输的用户无法更改，如果更改了就会和签名核对不上，通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息，如果有不能公开的信息可以再做一层加密后再放入payload
用户如果更换了昵称，如何快速更换 token 中保存的用户昵称呢？
- 客户端可以缓存修改后的昵称，直到更换了access token再清除缓存，类似弹幕本地先发送让用户自己认为发送成功
- 有些为了业务方便，token可以有额外的信息放在结尾，如果这个信息用户常修改则不应该放在token里面，单独弄个接口不是直接解决问题。