单点登录架构
# 单点登录
## 理论知识
### 单点登录是什么?
> 有一个误区, 单点登录并不是说点击一下头像, 不需要用户名和密码就可以登录, 这不是单点登录
> 单点登录真正的含义类似于一键登录, 即当你有很多个项目, 这些项目共用一个用户表, 即比如有百度, 百度贴吧, 百度网盘, 想要登录百度, 旗下的所有产品都同步登录, 这才是单点登录
> 简而言之, 单点登录是所有产品的一键登录
### 多系统为什么要单点登录
> 多系统换句话来说就是多产品, 如果没有单点登录, 每个都去登录一下, 而且登录的内容完全一模一样, 用户体验很差, 没有必要, 所以需要单点登录
### 为什么session无法做单点登录
> 因为有一个非常致命的问题, 即Cookie的作用范围, Cookie作用范围是域名及其子域名的所有路径, 但是多产品有一个很致命的问题, 就是不同产品之间的域名完全不一样, 根本找不出共同的父域名, 因此, cookie无法在两个不同的应用之间共享, 因此, 就无法共享登录信息, 因此, session无法做单点登录
### 单点登录不能用Feign调用微服务, 为什么?
> 因为单点登录的场景下, 需要一个登录认证服务器, 登录认证服务器的架构是未知的, 如果不是Java, Fegin根本调用不了, 即使用了Java, 如果没有加入Nacos也服务发现不了, 因此, Feign调用时不被允许的
### 仅仅知道访问令牌有什么问题?
> 如果仅仅知道访问令牌, 另外的产品仍然需要登录, 换而言之, 一键登录还是没有解决, 本质原因是这样做并不能共享Cookie, 一个产品登陆了, 另一个产品并不能获取访问令牌
> 为了让第二个产品也能获取访问令牌, 我们可以在登录服务器存储Cookie, 同一个浏览器下, 不论是访问哪个产品, 一旦发现没有登录一定会跳转登录服务器, 如果存在对应的Cookie, 说明之前登陆过了, 直接后端给你登陆了, 给你以一键登录的错觉
> 简而言之, 通过第三方登录存储Cookie, 实现间接的Cookie共享, 让用户觉得一键登录的效果, 本质原因是后端因为Cookie帮我们一键登录了
### 有了访问令牌为什么需要发请求获取数据?
> 因为对于我们微服务而言, 登录服务器相当于一个盲盒, 我们无从得知这个访问令牌是什么, 或者数据存储到哪里, 因此, 我们需要通过访问令牌来交换数据
## 时序图
### 架构思想
> 为了实现3|4, 通过在中央认证服务器中存储Cookie库来实现
> 为了实现2, 通过响应重定向携带原请求地址来实现
> 这里最重要的就是中央认证服务器的Cookie, 他灵活的解决了Cookie不能共享到多个域名的难题, 另外就是重定向携带原地址, 这也是非常灵活的回调
### 注销的细节
> 如果要注销登录, 不仅需要将一致性存储的会话信息删除, 还需要将认证中心的Cookie删除