多方案统一认证体系对比

在多系统、多子域、跨平台应用中，认证与登录状态同步是核心问题。不同架构阶段可采用不同方案，从传统 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，所有子域共享。
  

流程示意

1. [main.example.com] 登录成功
2.    ↓
3. Set-Cookie: sid=abc123; Domain=.example.com; HttpOnly; Secure
4.    ↓
5. [learn.example.com] 自动携带同 Cookie
6.    ↓
7. Session 服务验证 sid 是否有效

复制代码

优点

• 实现简单，兼容旧系统。
  
• 后端集中控制登录、登出状态。
  

缺点

• 有状态，需集中存储。
  
• 仅限同主域子域共享，不支持跨主域或移动端。
  

Session + Token 双层模型

核心思想

结合 Session 管理 Web 登录状态 + Token 管理 API 调用。
凭证存放位置用途sidCookie（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 验证自动登录。
  

流程示例

1. [appA.example.com] → Redirect → [auth.example.com/login]
2.                                         ↓
3.                           用户登录 → 颁发 Token
4.                                         ↓
5. [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 Token5–30 分钟前端内存 / LocalStorage请求 API 用Refresh Token7–30 天HttpOnly Cookie / 安全存储刷新 Access Token登录与刷新流程

1. 1. 用户登录 → 返回 access_token + refresh_token
2. 2. access_token 调用 API
3. 3. 过期后使用 refresh_token 刷新
4. 4. 登出时失效 refresh_token

复制代码

优点

• 完全无状态，服务端仅验证签名。
  
• 适合移动端、Web、第三方系统。
  
• 标准协议（OAuth2 / OIDC），支持扩展生态。
  

缺点

• 需建立完整的认证授权体系。
  
• Token 泄露风险需严格控制（短期 + 黑名单）。
  

安全机制与策略对比

安全策略集中 SessionSession+Token标准 SSOToken+TokenHTTPS 强制✅✅✅✅HttpOnly Cookie✅✅✅✅（仅 Refresh）Token 过期机制❌自定义✅✅ 标准化跨域支持⚠️ 仅同主域同主域 + 内部跨域✅✅ 完全支持移动端兼容❌有限✅✅ 完美支持黑名单吊销✅（sid）自定义✅✅ Refresh 黑名单四种方案总体对比

对比项集中 SessionSession+Token标准 SSOToken+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）：完全无状态的现代化统一认证，是最终推荐架构。
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！