多方案统一认证体系对比

在多系统、多子域、跨平台应用中，认证与登录状态同步是核心问题。不同架构阶段可采用不同方案，从传统 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）：完全无状态的现代化统一认证，是最终推荐架构。