SSO单点登录原理与CAS架构详解：从核心流程到系统设计

单点登录（Single Sign-On，简称 SSO）是大型分布式架构的重要基石，它允许用户仅需进行一次身份验证，即可访问多个相互信任的应用系统，而无需重复登录。

这不仅极大地提升了用户体验，也简化了系统的身份认证管理，尤其适用于微服务、多应用门户等复杂的分布式系统环境。

图1：SSO单点登录概念示意

单点登录的核心原理

单点登录的核心本质在于：身份认证的集中化。认证操作只在统一的 SSO 认证中心执行一次，而产生的认证结果（凭证）可以被下游所有业务系统所信任和复用。因此，其关键技术并非“登录”本身，而是“认证状态如何安全、可靠地在不同系统间传递与校验”。

一个典型的 SSO 系统架构通常包含以下三个核心角色：

┌──────────┐
│  Browser │
└────┬─────┘
     │
     ▼
┌────────────┐        ┌────────────────┐
│  Client A  │◄──────►│   SSO Server   │
│  Client B  │        │ (认证中心)     │
│  Client C  │        └────────────────┘
└────────────┘

1. CAS Server（认证中心）
这是整个体系中唯一负责执行“用户名/密码校验”等核心身份认证逻辑的系统。其主要职责包括：

• 校验用户凭证（如账号密码）。
• 创建并维护全局的登录态（如 Ticket Granting Ticket, TGT）。
• 根据请求签发一次性的服务票据（Service Ticket, ST）。
• 作为统一登出的协调中心。

2. CAS Client（业务应用）
各个需要接入 SSO 的业务系统本身不再处理登录逻辑，它们只专注于一件事：票据校验。其核心职责是：

• 拦截访问受限资源但未本地登录的请求。
• 将用户请求重定向至 CAS Server 进行认证。
• 在后台向 CAS Server 验证收到的服务票据（ST）的合法性。

3. 浏览器（Browser）
浏览器作为用户交互和跳转的载体，负责在 CAS Server 与各个 Client 之间传递认证票据（Ticket），并通过 Cookie 来维持与认证中心之间的会话（TGC）。

基于CAS协议的单点登录流程详解

整个单点登录的交互流程，可以清晰地通过以下步骤来理解：

图2：基于CAS协议的认证交互流程图

1. 访问受限资源：用户通过浏览器尝试访问 Client A 的某个受保护页面。
2. 发现未登录：Client A 检查发现当前请求没有有效的本地会话（Local Session），判定用户未登录。
3. 重定向至认证中心：Client A 向浏览器返回一个 302 重定向响应，引导浏览器跳转到 CAS Server 的登录地址，并附上自己的服务地址（Service URL）作为参数。
4. 统一身份认证：CAS Server 接收到请求后，检查浏览器是否存在有效的认证中心 Cookie（TGC）。如果不存在，则向用户展示登录页面。用户在此输入账号和密码进行认证。
5. 签发服务票据：认证成功后，CAS Server 会生成一个一次性、短有效期的服务票据（ST），然后再次通过 302 重定向，将浏览器带回到 Client A 的服务地址，并将 ST 作为URL参数传递。
6. 后台票据验证：Client A 从URL参数中拿到 ST 后，会在服务器后台（不经过浏览器）秘密地向 CAS Server 发起一个请求，专门用于验证此 ST 的有效性。
7. 建立本地会话：CAS Server 验证 ST 合法后，将对应的用户标识信息返回给 Client A。Client A 随即为该用户创建本地会话（Session），登录完成，用户可正常访问资源。
8. 访问其他系统：当同一用户再去访问 Client B 时，会重复步骤1-3。但当跳转到 CAS Server 时，由于浏览器已持有有效的 TGC Cookie，认证中心会直接发现用户已登录，从而跳过登录页面，直接为 Client B 签发新的 ST，并完成后续验证流程，实现“单点”登录。

这种设计确保了用户凭证（密码）只在最受信任的认证中心提交一次，业务系统之间通过可验证的票据来传递信任，兼顾了安全性与便利性。

如果你对分布式系统架构的更多核心知识感兴趣，欢迎访问云栈社区进行深入探讨与学习。