在多系统、多子域、跨平台应用中，认证与登录状态同步是核心问题。不同架构阶段可采用不同方案，从传统 Session 模型到标准化 OAuth2 / OIDC SSO。域下的登录态共享可以看看之前文章提到了域登录态分享类 SSO。
现在简单介绍下四种常见方案：
- 集中 Session 模型（同主域多子域场景）
- Session + Token 双层模型（兼顾 Web 与 API）
- 标准 SSO（单点登录）模型（跳转式统一认证）
- Token + Token 模型（OAuth2 / OIDC 标准实现）
集中 Session 模型
适用场景
- 同一主域下的多个子域系统（如
main.example.com、learn.example.com）。 - 不需要第三方授权或移动端接入。
核心机制
- 后端统一维护 Session 表，存储 sid → 用户映射。
- 登录后通过
Set-Cookie写入sid到.example.com，所有子域共享。
流程示意
[main.example.com] 登录成功↓
Set-Cookie: sid=abc123; Domain=.example.com; HttpOnly; Secure↓
[learn.example.com] 自动携带同 Cookie↓
Session 服务验证 sid 是否有效
优点
- 实现简单，兼容旧系统。
- 后端集中控制登录、登出状态。
缺点
- 有状态，需集中存储。
- 仅限同主域子域共享，不支持跨主域或移动端。
Session + Token 双层模型
核心思想
结合 Session 管理 Web 登录状态 + Token 管理 API 调用。
| 凭证 | 存放位置 | 用途 |
|---|---|---|
| sid | Cookie（HttpOnly） | 管理浏览器登录会话 |
| Access Token (JWT) | Header (Authorization) |
访问后端 API |
登录流程
- 用户登录，认证中心生成 sid + token；
sid写入.example.com域 Cookie；- 返回
access_token用于前端调用 API； - 其他子域共享登录状态，或刷新 token。
续期机制
- sid 过期前可用于刷新 token；
- token 过期后通过 sid 自动续签。
优点
- Web 自动登录 + API 鉴权并存。
- 内部系统平滑过渡至无状态认证。
缺点
- 仍依赖 Session 存储中心。
- 无标准协议定义，不适合外部接入。
标准 SSO（单点登录）模型
核心理念
- 所有系统共用统一 认证中心（Auth Server）；
- 用户只需登录一次，其他系统通过跳转 + Token 验证自动登录。
流程示例
[appA.example.com] → Redirect → [auth.example.com/login]↓用户登录 → 颁发 Token↓
[auth.example.com] → Redirect → [appB.example.com/callback?token=xxx]
特点
- 各系统独立域名可共享登录状态；
- 登录态由认证中心统一管理；
- 可基于 Cookie + Token 混合方式维持。
优点
- 实现真正的“单点登录 / 登出”；
- 登录体验一致；
- 可跨主域、多平台。
缺点
- 实现复杂（需独立认证中心）。
- 对前端跳转依赖较强。
Token + Token 模型（OAuth2 / OIDC 标准 SSO）
核心机制
OAuth2 / OIDC 标准双 Token 模式：
- Access Token：短期访问令牌，用于鉴权。
- Refresh Token：长期刷新令牌，用于续签。
| Token 类型 | 有效期 | 存储方式 | 说明 |
|---|---|---|---|
| Access Token | 5–30 分钟 | 前端内存 / LocalStorage | 请求 API 用 |
| Refresh Token | 7–30 天 | HttpOnly Cookie / 安全存储 | 刷新 Access Token |
登录与刷新流程
1. 用户登录 → 返回 access_token + refresh_token
2. access_token 调用 API
3. 过期后使用 refresh_token 刷新
4. 登出时失效 refresh_token
优点
- 完全无状态，服务端仅验证签名。
- 适合移动端、Web、第三方系统。
- 标准协议（OAuth2 / OIDC），支持扩展生态。
缺点
- 需建立完整的认证授权体系。
- Token 泄露风险需严格控制（短期 + 黑名单）。
安全机制与策略对比
| 安全策略 | 集中 Session | Session+Token | 标准 SSO | Token+Token |
|---|---|---|---|---|
| HTTPS 强制 | ✅ | ✅ | ✅ | ✅ |
| HttpOnly Cookie | ✅ | ✅ | ✅ | ✅（仅 Refresh） |
| Token 过期机制 | ❌ | 自定义 | ✅ | ✅ 标准化 |
| 跨域支持 | ⚠️ 仅同主域 | 同主域 + 内部跨域 | ✅ | ✅ 完全支持 |
| 移动端兼容 | ❌ | 有限 | ✅ | ✅ 完美支持 |
| 黑名单吊销 | ✅（sid） | 自定义 | ✅ | ✅ Refresh 黑名单 |
四种方案总体对比
| 对比项 | 集中 Session | Session+Token | 标准 SSO | Token+Token（OAuth2/OIDC） |
|---|---|---|---|---|
| 状态类型 | 有状态 | 半无状态 | 半无状态 | 无状态 |
| 实现复杂度 | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 安全性 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 跨域支持 | ⚠️ 限制 | ✅ 同主域 | ✅ 多主域 | ✅ 完全支持 |
| 扩展性 | 内部系统 | Web + API | ✅ 外部接入 | ✅ 标准生态 |
| 标准协议 | ❌ | ❌ | 简化版 | ✅ OAuth2 / OIDC |
| 推荐场景 | 同主域多子系统 | 内部 SPA + API | 多系统统一登录 | 跨域 / 移动端 / 第三方平台 |
结论与演进建议
| 当前阶段 | 推荐方案 | 演进方向 |
|---|---|---|
| 内部多子域系统 | 集中 Session | → Session+Token |
| 前后端分离系统 | Session+Token | → 标准 SSO |
| 跨域 / 多系统接入 | 标准 SSO | → Token+Token 模式 |
| 对外平台 / 移动端 | Token+Token | ✅ 最终形态 |
总结：
- 集中 Session：适合简单、同主域系统。
- Session + Token：过渡方案，兼容 API。
- 标准 SSO：多域单点登录实现。
- Token + Token（OAuth2/OIDC）：完全无状态的现代化统一认证，是最终推荐架构。