登录单点登录（SSO）在前端世界的落地形态
上一章我们聊了 OAuth2 与第三方登录的三个阶段：从 Implicit Flow 的混乱时代，到 PKCE 的安全崛起，再到 OAuth 2.1 + 一键登录的无感体验。但 OAuth/OIDC 主要解决的是“授权 + 身份认证”，在企业内部多系统间实现“一次登录、处处可用”的真正 SSO 时，前端还需要面对更复杂的落地挑战：跨域、跨顶级域、微前端、浏览器隐私策略变化等。
这一篇，我们从前端视角拆解 SSO 的主流落地形态，重点对比三种核心实现方式，并讨论 2024–2026 年浏览器变化（第三方 Cookie 逐步淘汰）带来的冲击与应对。
1. SSO 在前端的核心职责与挑战（2026 年视角）
前端在 SSO 中的真实角色：
- 检测登录状态（silent check）
- 无感跳转 / 刷新 token
- 跨应用同步登录/登出状态
- 处理跨域（子域 / 不同顶级域）
- 兼容隐私沙盒（Chrome Partitioned Cookies、Storage Partitioning）
2025–2026 年最大变化：
- 第三方 Cookie 基本被禁用（Chrome 100% rollout）
- Storage Partitioning（不同顶级域的 localStorage 分区）
- iframe + postMessage 方案受限（但仍可部分工作）
因此，纯 Cookie 共享 → 纯 Token 集中 → 混合 / BFF 模式 成为主流演进路径。
2. 三种主流前端 SSO 落地方式对比（2024–2026 现状）
| 实现方式 | 适用场景 | 跨域支持 | 依赖第三方 Cookie | 浏览器兼容性（2026） | 安全性 | 复杂度 | 代表方案 / 协议 | 当前流行度 |
|---|---|---|---|---|---|---|---|---|
| 基于 Cookie 的域共享 | 子域 SSO（*.company.com） | 子域 / 同顶级域 | 是（顶级域 Cookie） | 高（SameSite=None+Secure） | 中–高 | 低 | CAS、SAML、OIDC Cookie 模式 | ★★★☆☆ |
| 基于 Token 的集中式认证 | 跨顶级域、多 SPA、微前端 | 任意域 | 否 | 最高（无 Cookie 依赖） | 高 | 中–高 | OIDC + PKCE + Refresh Token | ★★★★★ |
| iframe + postMessage 通信 | 遗留系统、临时桥接 | 跨域 | 部分（或无） | 中（分区 + 限制） | 中–低 | 高 | 早期 CAS、Zendesk cross-storage | ★☆☆☆☆ |
方式一：基于 Cookie 的域共享（最传统、最简单）
适用：所有应用在同一顶级域下（如 app1.company.com、app2.company.com、sso.company.com）
核心机制：
- SSO 服务器 Set-Cookie 时设置
domain=.company.com; Secure; HttpOnly; SameSite=Lax/None - 浏览器在所有子域自动携带该 Cookie
- 前端几乎无感：只需检查 Cookie 或调用
/userinfo接口
优点：浏览器原生、无需前端代码干预、登出可直接删 Cookie
缺点：
- 仅限子域（跨顶级域失效）
- 第三方 Cookie 限制下需
SameSite=None; Secure+ 用户许可 - 不适合微前端 / 多顶级域场景
2026 年现状：企业内网、传统 ToB 系统仍大量使用，但新项目已转向 Token 模式。
方式二：基于 Token 的集中式认证（目前最推荐、最主流）
适用：跨顶级域、多前端（React/Vue/Next.js + 微前端）、移动 + Web 混合
核心流程（OIDC + Authorization Code + PKCE + Refresh Token）：
- 用户访问任意前端 → 未登录 → 重定向到 SSO 中心（
/authorize） - SSO 中心登录成功 → 返回 code → 前端（或 BFF）用 PKCE 换 token（access_token + id_token + refresh_token）
- 前端存储 refresh_token（HttpOnly Cookie 或 secure storage），access_token 放内存 / localStorage（短效）
- 所有前端共享同一 SSO 中心 → 登录一次，后续 silent renew（iframe 或 refresh token）
- 登出：调用
/logout+ 清本地 token + 通知其他 tab（BroadcastChannel / localStorage 事件）
前端关键实现点：
- Silent authentication：hidden iframe 打开 authorize endpoint（check session）
- Refresh：用 refresh_token 静默换新 access_token
- 多应用同步：BroadcastChannel 或 Service Worker 监听登录/登出事件
代表方案：
- Auth0 / Okta / Clerk / Supabase Auth / Keycloak（OIDC 模式）
- NextAuth / Lucia + OIDC provider
- 自建：oidc-client-ts / @auth0/auth0-spa-js
2026 年优势：
- 无第三方 Cookie 依赖
- 支持跨顶级域
- 与微前端兼容（各子应用独立管理 token，但共享 SSO 会话）
痛点：
- 前端需处理 token 刷新、silent renew、登出广播
- refresh_token 安全存储（推荐 BFF 或 HttpOnly Cookie）
方式三：iframe + postMessage（逐渐被淘汰的过渡方案）
早期流行于跨域 SSO（不同顶级域），典型库：cross-storage、pym.js
机制：
- 主应用嵌入 hidden iframe 指向 SSO 域
- iframe 内登录 → localStorage 写 token
- postMessage 通知父窗口 → 父窗口读取
2023–2025 年后问题：
- Storage Partitioning（Chrome 等）让跨顶级域 localStorage 隔离
- iframe sandbox 限制 + 第三方 Cookie 禁用
- 性能差、SEO 问题、用户体验差
2026 年现状：仅遗留系统或极特殊场景使用，新项目已弃用。
3. 微前端 / 多 SPA 下的 SSO 特殊痛点与解决方案
微前端（qiankun、Module Federation、single-spa）常见场景：
- 不同子应用可能不同框架、不同构建
- 需要统一登录状态
解决方案（2025–2026 推荐）：
- 统一 SSO 中心 + Token 模式：所有子应用用同一 OIDC Client ID，共享 refresh_token（通过主应用分发或 BFF）
- 主应用代理登录：基座应用负责 silent check 和 token 管理，子应用通过 props / 事件总线获取状态
- BroadcastChannel + localStorage 事件：登录/登出时广播，子应用监听同步
- BFF（Backend for Frontend）：每个子应用有独立 BFF，BFF 持 refresh_token，前端只拿短效 access_token
4. 2026 年 SSO 前端 Checklist（实用建议）
- 优先选 OIDC + PKCE + Refresh Token Rotation
- 避免依赖第三方 Cookie（除非子域 + SameSite=None）
- 使用成熟 SDK（oidc-client-ts、@auth0/auth0-spa-js、next-auth）
- Silent renew 用 refresh_token 而非 iframe（更可靠）
- 登出需调用 end_session_endpoint + 清本地 + 广播
- 高安全场景用 BFF 模式（token 永不出现在浏览器 JS）
- 测试隐私沙盒：Chrome Incognito + 第三方 Cookie 禁用
小结 & 过渡
前端 SSO 从 Cookie 域共享 → iframe 桥接 → Token 集中式（OIDC 主导）的演进，本质上是适应浏览器隐私保护 + 跨域需求的过程。
2026 年，基于 OIDC + Refresh Token 的集中式认证 是最主流、最可靠的落地形态，尤其适合现代 Web / 微前端 / 跨域场景。
