单点登录

场景：公司有很多个子系统，希望子系统共享一套用户数据，用户认证都是属于一套认证中心代码

1. session + cookie 模式

1. 登录 ---> 认证中心
2. 认证中心验证完成，在服务器的Redis数据库中开一个session表格，新增一个键值对[sid:身份信息]
3. 认证中心返回cookie：sid，用户存储cookie
4. 用户访问子系统A时候携带cookie:sid
5. 子系统A请求sid到认证中心，认证中心查询结果返回给子系统A

我想让谁下线，我只需要在认证中心删除session键值对 或 将用户数据加入黑名单 就下线了，符合大厂对于用户的强控制力

缺点：要实现这种强控制力，都需要向认证中心发送请求，所以认证中心负载非常大，比较烧钱，所以就有了Token模式

2. token模式

1. 登录 ---> 认证中心
2. 返回jwt的不可以被篡改的token
3. 用户携带token请求去获取子系统A的内容，子系统会独立验证，不用找认证中心

如果子系统A想让用户下线，就需要和认证中心沟通，然后再由认证中心去广播给其他子系统，所以就会比较麻烦，缺少强控制力，比较麻烦，所以有了双token模式

3. 双token：TOKEN+RefreshTOKEN模式

1. 登录
2. 返回token + refreshtoken
3. 获取子系统A或B时候携带短token，如果此时短token失效了，就会让用户使用长token去和认证中心获取新的短token

这里，如果子系统不想让用户登录，只需要和认证中心沟通，不让用户交换获取新的短token，就能让用户在旧短token失效的时候无法获取新的短token而登录其他系统，从而实现一定程度上的控制，避免完全失控ß

手动刷新

• 首先需要两个Token:
  • 一个长token，用于获取用户数据和短token;
  • 短token，用于获取登录后的某些数据
• 长token在企业级别的系统中一般是1周到1个月之间，短token可能是几个小时，不到半天

手动刷新的逻辑：

1. 先登录，获取长token，短token，存储到本地
2. 点击刷新按钮，发送刷新请求，请求刷新token接口，获取新的短token, 并存储到本地

无感刷新

• 发现短token过期

1. 用长换短
2. 重新请求

• 长token也过期

1. 长短同时过期，直接跳转重新登录