背景

内容是极客时间-徐长龙老师的高并发系统实战课的个人学习笔记，欢迎大家学习！https://time.geekbang.org/column/article/596644

使用Session方式实现用户的用户鉴权

优点

信息都在服务端储存，对客户端不暴露任何用户敏感的数据信息

缺点

1. Session Cache空间会变得很大
2. 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的方式完全可以结合起来用

1. Session 耦合性高，实时性高
2. Token 耦合性不高，实时性低

问题

使用base64加密是不是不太安全？这样不是很容易知道你用什么加密算法了

这个算法重点并不是这个payload区，payload这里只是附带的数据，只是为了方便业务使用，事实上这个核心在于签名和过期时间，由于密钥是只有服务端有，所以签名是不能伪造的，如果到子业务这里验证签名是正确的密钥加密的，那么代表token的payload的内容肯定是服务器发放的，传输的用户无法更改，如果更改了就会和签名核对不上，通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息，如果有不能公开的信息可以再做一层加密后再放入payload

用户如果更换了昵称，如何快速更换 token 中保存的用户昵称呢？

1. 客户端可以缓存修改后的昵称，直到更换了access token再清除缓存，类似弹幕本地先发送让用户自己认为发送成功
2. 有些为了业务方便，token可以有额外的信息放在结尾，如果这个信息用户常修改则不应该放在token里面，单独弄个接口不是直接解决问题。