sso三种模式登入实现思路

1.SSO 模式一（前端同域，后端同redis）

首先我们分析一下多个系统之间，为什么无法同步登录状态？

1. 前端的 Token 无法在多个系统下共享。
2. 后端的 Session 无法在多个系统间共享。

所以单点登录第一招，就是对症下药：

1. 使用 共享Cookie 来解决 Token 共享问题。
2. 使用 Redis 来解决 Session 共享问题。

所谓共享Cookie，就是主域名Cookie在二级域名下的共享，举个例子：写在父域名stp.com下的Cookie，在s1.stp.com、s2.stp.com等子域名都是可以共享访问的。

而共享Redis，并不需要我们把所有项目的数据都放在同一个Redis中，Sa-Token提供了 [权限缓存与业务缓存分离] 的解决方案，详情戳：Alone独立Redis插件。

2.sso 模式二（前端不同域，后端同redis）

如果我们的多个系统：部署在不同的域名之下，但是后端可以连接同一个Redis，那么便可以使用 [URL重定向传播会话] 的方式做到单点登录。

首先我们再次复习一下，多个系统之间为什么无法同步登录状态？

1. 前端的Token无法在多个系统下共享。
2. 后端的Session无法在多个系统间共享。

关于第二点，我们已在 "SSO模式一" 章节中阐述，使用 Alone独立Redis插件 做到权限缓存直连 SSO-Redis 数据中心，在此不再赘述。

而第一点，才是我们解决问题的关键所在，在跨域模式下，意味着 "共享Cookie方案" 的失效，我们必须采用一种新的方案来传递Token。

1. 用户在 子系统 点击 [登录] 按钮。
2. 用户跳转到子系统登录接口 /sso/login，并携带 back参数 记录初始页面URL。
   • 形如：http://{sso-client}/sso/login?back=xxx
3. 子系统检测到此用户尚未登录，再次将其重定向至SSO认证中心，并携带redirect参数记录子系统的登录页URL。
   • 形如：http://{sso-server}/sso/auth?redirect=xxx?back=xxx
4. 用户进入了 SSO认证中心 的登录页面，开始登录。
5. 用户 输入账号密码 并 登录成功，SSO认证中心再次将用户重定向至子系统的登录接口/sso/login，并携带ticket码参数。
   • 形如：http://{sso-client}/sso/login?back=xxx&ticket=xxxxxxxxx
6. 子系统根据 ticket码 从 SSO-Redis 中获取账号id，并在子系统登录此账号会话。
7. 子系统将用户再次重定向至最初始的 back 页面。

整个过程，除了第四步用户在SSO认证中心登录时会被打断，其余过程均是自动化的，当用户在另一个子系统再次点击[登录]按钮，由于此用户在SSO认证中心已有会话存在， 所以第四步也将自动化，也就是单点登录的最终目的 —— 一次登录，处处通行

3.sso模式三（前端不同域，后端不同redis）

因为前端不同域登入流程和模式二一样（使用 [URL重定向传播会话] 的方式做到单点登录）

sso三种模式的优缺点

模式一：

                    优点：1.不需要开发开发sso服务端和对接sso服务端，通过父级域名共享Cookie 

                               2. 单点登出简单（通过同redis实现Session 共享问题）

                    缺点：1.对接项目必须是父域名下二级域名

                               2.所有对接项目都要通过同一个redis来存储session（干扰对接项目原本存储redis的方式）

模式二：

                    优点：1.不需要要求对接项目是父级域名下的二级域名

                               2. 单点登出简单（通过同redis实现Session 共享问题）

                    缺点：1.对接复杂（开发客户端和sso服务--url重定向传播会话）

                               2.所有对接项目都要通过同一个redis来存储session（干扰对接项目原本存储session的方式）

模式三：

                    优点：1.不需要要求对接项目是父级域名下的二级域名

                               2.不干扰对接项目原本存储session的方式

                    缺点：

                              1.对接复杂（开发客户端和sso服务--url重定向传播会话）

                              2.单点登出复杂，需要通过对接客户提供登出接口，sso服务端一一通知登出

模式三单点登出逻辑

单点登出动态图

有了单点登录就必然要有单点注销，网上给出的大多数解决方案是将注销请求重定向至SSO-Server中心，逐个通知Client端下线

在某些场景下，页面的跳转可能造成不太好的用户体验，Sa-Token-SSO 允许你以 REST API 的形式构建接口，做到页面无刷新单点注销。

1. Client 端在校验 ticket 时，将注销回调地址发送到 Server 端。
2. Server 端将此 Client 的注销回调地址存储到 Set 集合。
3. Client 端向 Server 端发送单点注销请求。
4. Server 端遍历Set集合，逐个通知 Client 端下线。
5. Server 端注销下线。
6. 单点注销完成