什么是 SSO 单点登录？CAS 方案和 OAuth2/OIDC 方案有什么区别？
- 标签：Spring Security、认证授权、后端
🏛 业务架构师
SSO（Single Sign-On，单点登录）：一次登录，访问集团内多个系统无需重复认证——用户体验与账号治理（一处注销、全线下线）的双赢。
CAS 方案（传统，高校/政企常见）：
- 流程：访问业务系统 → 无本地会话 → 重定向 CAS Server 登录 → 登录后 CAS 发 Ticket（ST）回调业务系统 → 业务系统拿 Ticket 到 CAS 验证 → 建立本地 Session；
- 特点：基于中心化会话（CAS 的 TGT/Session）；协议自成体系；客户端为 Java 生态成熟（CAS Client/Java CAS Client）；适合内网传统 Web 应用集群；现代 OIDC 场景下维护社区在萎缩。
OAuth2/OIDC 方案（现代主流）：
- 流程：业务系统作为 OIDC Client，重定向到 Identity Provider（Keycloak、Authing、Azure AD）授权码+PKCE 登录 → 拿 ID Token（JWT）验证身份 → 建立本地会话/Token；
- 特点：标准协议（接入任何支持 OIDC 的系统即插即用）、Token 无状态、天然支持 App/小程序/SPA 多端、生态工具链丰富（JWKS 验签、刷新、多因素认证都是标配）；配合 OIDC 的单点登出（front/back-channel logout）实现一处登出全线下线。
区别总结（选型视角）：
| 维度 | CAS | OIDC |
|---|---|---|
| 协议地位 | 自有协议，生态收缩 | 开放标准，事实主流 |
| 客户端形态 | 以传统 Web 为主 | Web/App/小程序/服务全覆盖 |
| 会话模型 | 中心会话 | Token 为主，混合可选 |
| 新建系统 | 一般不再选 | 默认答案 |
我的建议：存量 CAS 集群维护即可；新建/改造统一身份平台——OIDC（Keycloak/IDaaS）是 2026 年唯一理性选择，且选型时验证好单点登出与多租户能力（B 端的硬需求）。技术选型要看社区十年的斜率，不看今天的存量。
🏗 系统架构师
SSO = 一次登录、处处通行——多系统共享认证态，用户只在身份提供方（IdP）认证一次。核心机制是**"认证中心 + 令牌/票据交换"**，CAS 与 OAuth2/OIDC 是两代实现：
CAS（Central Authentication Service，耶鲁出品）：
- 协议主角是 Ticket：应用重定向到 CAS Server 登录 → 认证后回调带 ST（Service Ticket，一次性短命） → 应用后端拿 ST 到 CAS Server 验证（服务器到服务器）换回用户身份——ST 一次性防重放；
- 会话模型：各应用自建本地会话 + 全局 TGT/TGC（CAS 的全局会话 Cookie）——单点登出靠 CAS 通知各应用销毁本地会话（back-channel）；
- 特点：协议简单、自建部署的传统校园/企业标准；XML/自定义协议，生态偏 Java 系（CAS Server 本身是 Spring 项目）。
OAuth2/OIDC 方案：
- 现代标准：OIDC 授权码 + PKCE 流程做 SSO（ID Token 是认证证明），Bearer JWT 做 API 访问；
- 生态与协议标准化：
/.well-known发现、JWKS 密钥、多 IdP 联邦（社交登录/企业 IdP 互联）、标准化的 refresh/登出（front/back-channel logout）； - 令牌自包含（JWT 本地验签，微服务天然共享）。
架构对比与选型：
| 维度 | CAS | OIDC/OAuth2 |
|---|---|---|
| 语义 | 纯认证（SSO） | 认证+授权一体（OIDC+OAuth2） |
| 协议 | 自定义/XML | REST/JSON 标准化 |
| 生态 | 企业内网、Java 系 | 全行业、API/移动端/云原生 |
| 微服务适配 | 会话型，较重 | JWT 无状态天然契合 |
| 登出 | 成熟（back-channel） | 标准化演进中（OIDC Logout） |
选型：新系统一律 OIDC（Keycloak/Auth0/自建 Spring Authorization Server）；存量 CAS 校园/政企可保留并用（CAS 协议桥接 OIDC 的网关转换渐进迁移）。共同架构本质：认证集中化（IdP 是唯一知道密码的地方），应用只消费认证结果。
💻 全栈开发专家
SSO（单点登录）：一处登录、处处通行——用户在身份中心认证一次，访问多个子系统无需重复登录；对应有单点登出（一处登出全端失效）。
CAS 方案（高校/传统企业的老牌协议）：
- 流程：访问子系统 → 无本地会话 → 302 到 CAS Server（带 service 参数）→ CAS 认证（账密）→ 带 ticket 重定向回来 → 子系统后端向 CAS 验证 ticket（/serviceValidate）→ 建立本地 session；
- 特点：基于中心会话 + 各系统本地会话（双层会话）；协议简单专一（就是登录）；票据一次性；生态成熟（Apereo CAS）。
OAuth2/OIDC 方案（现代标准）：
- OIDC 登录：授权码 + PKCE 流程，授权中心（IdP）登录后发 code → 换 access_token + id_token（JWT，含用户身份）→ 应用验 id_token 建立会话；
- 特点：标准化、JSON/REST、无状态 token 可选；不止登录，还带授权（scope）、UserInfo、Discovery、多因素、社交登录生态；Spring Security/Keycloak/Auth0 原生支持。
| 维度 | CAS | OIDC |
|---|---|---|
| 定位 | 仅认证 | 认证+授权+用户信息全家桶 |
| 令牌 | 中心 session + ticket | id_token(JWT)/access_token |
| 扩展 | 移动端/API 支持弱 | 多端原生 |
| 现状 | 遗留系统 | 新项目唯一合理选择 |
选型（实战）：新系统/移动端/API → OIDC（Spring Authorization Server 或 Keycloak 自建，社交登录接 Authing/Auth0）；已有 CAS 的高校国企体系 → Keycloak 可 CAS 代理做桥接渐进迁移。
单点登出的差异：CAS 有标准登出协议（通知各子系统销毁 session）；OIDC 的 JWT 无状态登出难——用短有效期+refresh 吊销+token_version 方案补（Back-Channel Logout 是补丁标准）。