前言
在企业级应用集群中，如果用户每打开一个内部系统都要重新输入一次密码，体验将是灾难性的。SSO（Single Sign-On） 的出现解决了这一痛点：它允许用户"一处登录，处处通行"。本文将深度拆解 SSO 的两种核心实现逻辑。
SSO 的核心概念
SSO（单点登录） 是指在多个应用系统中，用户只需要登录一次，就可以访问所有相互信任的应用系统。
典型场景： 登录了"支付宝"网页版后，直接打开"淘宝"、"天猫"或"阿里云"，你会发现自己已经处于登录状态。
二、 方案一：同域名下的 SSO（父域 Cookie 共享）
这是最简单的实现方式，利用了浏览器 Cookie 可以跨子域共享 的特性。
1. 实现原理
如果所有系统的域名都属于同一个顶级域名（如 a.company.com 和 b.company.com），我们可以将 Cookie 的 Domain 设置为父级域名 .company.com。
2. 执行流程
- 重定向： 用户访问业务系统 A，A 发现未登录，跳转至
sso.company.com。 - 认证： 用户在 SSO 页面完成登录。
- 种下全局 Cookie： SSO 验证成功，在响应头设置
Set-Cookie: sessionid=xxx; Domain=.company.com; Path=/，这样所有子域名系统都会自动带上这个 Cookie - 自动带入： 当用户跳转回系统 A 或访问系统 B 时，浏览器会自动带上这个
.company.com域下的 Cookie。 - 校验： 业务系统后端获取 Cookie 并请求 SSO 服务验证有效性，完成登录。
注意： 该方案仅适用于公司内部子系统，局限性在于必须处于同一父域下。
三、 方案二：跨域名下的 SSO（Token+code模式）
当系统域名完全不同（如 taobao.com 与 alipay.com）时，Cookie 无法跨域共享。此时需要一个独立的 统一认证中心（CAS/SSO） 。
核心流程：Token + Code 交换模式
1. 首次登录（以系统 A 为例）
- 路由拦截： 业务系统 A 的路由守卫发现本地无
token。 - 跳转认证： A 引导用户跳转至 SSO 登录页，并携带回跳地址：
https://sso.com/login?client_id=A&redirect_uri=https://a.com/callback。 - SSO 认证： 用户在 SSO 完成登录，SSO 在自己的域名（
sso.com）下种下 全局登录态 Cookie。 - 下发 Code： SSO 生成一个临时授权码 code ，通过 URL 重定向带回给系统 A：
https://a.com/callback?code=xxxxxx。 - 换取 Token： 系统 A 前端获取 code，再次向 SSO 服务发起请求。SSO 校验 Cookie + code 有效后，返回正式的
token。 - 本地存储： 系统 A 获取 token 后存储在
localStorage或本地Cookie中，登录成功。
2. 二次登录（访问系统 B）
- 无感跳转： 用户打开系统 B，B 发现未登录，跳转至 SSO 系统。
- Cookie 自动识别： 此时浏览器会自动带上
sso.com域下的全局 Cookie。 - 直接授权： SSO 发现用户已登录，直接生成一个新的 临时 code 并重定向回系统 B。
- B 换取 Token： 系统 B 使用新 code 换取属于 B 的
token，实现单点登录。
四、 注意事项
1. 为什么不直接返回 Token，而是用 Code 换取？
安全性。 如果直接在 URL 中返回 Token，Token 会暴露在浏览器历史记录中，容易被窃取。使用 临时 code（通常有效期仅 1-5 分钟且只能使用一次）配合后端校验，安全性更高。
2. 重定向时的"瞬间空白"如何处理？
跨域 SSO 在进行域名跳转时，由于需要经过 SSO 系统的中转判断，不可避免会有短暂的白屏或闪烁。
- UI 优化： 在重定向过程中展示一个统一的
Loading动画。 - 静默校验： 如果技术条件允许，可以通过
iframe尝试静默检查 SSO 登录态，减少全屏跳转。
3. 安全增强
- State 参数： 在跳转时增加一个随机字符串
state，并在回调时比对，防止 CSRF（跨站请求伪造） 攻击。 - HTTPS： SSO 全流程必须在 HTTPS 协议下进行，防止敏感信息被中间人劫持。
五、 总结
跨域 SSO 的核心思想是：将"身份验证"权力收拢到统一认证中心，利用 SSO 域下的 Cookie 维持全局登录态，通过"授权码交换"实现跨域权限传递。