理解SSO

单点登录系统（SSO）怎么实现，
企业级的SSO是一套基于认证中心的票据流程，记住一个核心，系统不要相信前端，每一次都得回中心去验票，具体过程是三次握手。
（1）直接访问业务系统A,系统发现你没有登录，二话不说把你重定向到认证中心；
（2）在中心完成登录，它会在自己的域名下给你种一个全局的cookie,证明你已经在总入口验证过你的身份，同时生成一个临时票据，再把你跳回系统A;
（3）关键系统A拿到票据，不是在客户端做校验，而是在后台偷偷去问认证中心，是否已经完成认证了，中心确认，A才会签发他自己的局部会话放进去，SSO的精髓就体现这里，当你再访问系统B的时候，认证中心一眼就能看到你，你浏览器里已经带着它的全域Cookie了，它知道你是验证过的老用户，所以不用你再输入密码，直接发一张新的票据给系统B,系统B后台验证通过，马上放行，一次登录到处访问，这个才是真正跑通了的底层逻辑。
如果在淘宝点退出，天猫怎么知道，这个就不是票据的事，这个涉及全局会话的失效广播，用redis发布订阅，还是用消息队列。

AI回答：
企业级单点登录（SSO）的核心设计思想是统一认证托管 + 后端验票机制：所有业务系统不独立做身份校验，全部由独立的认证中心统一管控；核心安全原则是：业务系统永远不能信任前端传入的身份信息，所有票据必须通过服务端到认证中心校验。

完整的实现逻辑分为「首次登录」「跨系统免登」「全局登出」三个核心环节：

---

一、首次登录流程（以访问业务系统 A 为例）

整体通过浏览器重定向完成身份流转，核心规则是「前端传票据、后端做校验」：

1. 重定向到认证中心
   用户访问业务系统 A，系统 A 校验本地会话不存在，将用户重定向到统一认证中心，同时携带自身的回调地址。
2. 认证中心完成身份认证
   认证中心校验自身域名下的全局会话 Cookie 不存在，引导用户输入账号密码完成登录。认证成功后：

• 在认证中心自身域名下写入全局会话 Cookie，标识用户已完成中心级认证；
• 生成一张一次性、短时有效的服务票据（ST），携带票据将用户重定向回业务系统 A 的回调地址。

3. 业务系统后端验票
   这是 SSO 最核心的安全设计：业务系统 A 拿到前端传来的票据后，不会直接信任，而是在服务端主动调用认证中心的校验接口，验证票据的合法性和对应的用户身份。
   认证中心校验通过后返回用户信息，系统 A 创建自身的本地会话，用户即可正常访问。

---

二、跨系统免登流程（访问业务系统 B）

这就是 “一次登录，处处访问” 的底层实现逻辑：
用户访问业务系统 B，系统 B 同样检测到无本地会话，重定向到认证中心。
此时认证中心可以读取到自身域名下的全局会话 Cookie，确认用户已经完成过认证，无需再次输入密码，直接生成对应系统 B 的服务票据，重定向回系统 B。
系统 B 同样执行后端验票、创建本地会话，用户全程无感知直接进入系统。

---

三、全局登出的实现（单点登出 SLO）

比如在淘宝登出后天猫同步失效，核心逻辑是全局会话销毁 + 各系统本地会话同步失效。
用户在任意业务系统触发登出后，认证中心首先销毁自身的全局会话，然后通过广播机制通知所有已登录的业务系统，销毁对应用户的本地会话。常见实现方案：

• Redis 发布订阅：认证中心发布用户登出消息，所有业务系统订阅对应频道，收到消息后清除本地会话；
• 消息队列广播：通过 MQ 发送登出广播消息，各业务系统消费后执行本地登出；
• 回调通知：认证中心维护各业务系统的登出回调地址，全局登出时依次回调各系统接口完成登出。

---

四、关键设计要点

1. 为什么必须后端验票：票据通过前端重定向传递，存在伪造风险，只有服务端之间的校验才能保证身份可信；
2. 票据特性：一次性、短时有效，即使被盗取也无法被重复使用，降低安全风险；
3. 会话隔离：认证中心维护全局会话，各业务系统维护自身本地会话，互不干扰，系统解耦性强。