什么是单点登录SSO？有哪些常用的实现方式？

约 2372 字大约 8 分钟

2025-10-13

引言：
每天上班要登录 OA、CRM、财务系统……密码多到记不住？一不小心全设成“123456”又怕被一锅端？别慌！单点登录（SSO）这把“万能钥匙”能救你于水火，但用不好也可能变成黑客的“黄金通行证”。今天我们就用大白话+图解，拆解 SSO 的奥秘及安全风险！

1. 什么是单点登录？

单点登录 (Single Sign-On, SSO) 是一种身份验证方案，允许用户使用一组凭据（例如，用户名和密码）访问多个应用程序或网站。这意味着用户只需登录一次，就可以访问所有被授权的系统，而无需为每个系统单独登录。

举个简单例子，你登录了百度账号（baidu.com/），接下来你再访问以下站点都将是登录状态，无需再重复登录。

百度网盘：pan.baidu.com/

百度文库：wenku.baidu.com/

文心一言：yiyan.baidu.com/

百度翻译：fanyi.baidu.com/

单点登录的核心目标就是为了提升用户体验，简化登录流程。

2. 为什么要用 SSO？

提升用户体验 ：用户只需记住一组登录凭据，即可访问多个系统，操作更便捷。
增强安全性和管理效率 ：减少密码数量，降低泄露风险，同时集中管理账户，简化运维工作。如果没有 SSO，员工在公司入职时，就需要为每一个应用注册账号，同样，在有员工离职时，管理员也要在每个应用中停用员工注册的账号。若有了 SSO，便可直接在 IdP（身份提供商）中删除其账号。
易于系统集成 ：实现跨应用的身份信息共享，提高系统间的协作与集成能力。

3. SSO 技术实现原理

SSO 有很多实现方式，如果应用的一级域名相同（上面百度的例子，一级域名都是 baidu），在用户登录成功后设置一个对所有子域名都生效的 Cookie，便可以在所有子域名应用（wenku、yige）中自动登录。

但是，要实现跨域单点登录，就不能使用简单的共享 Cookie 方案了，经典的跨域单点登录方式有：

CAS：Central Authentication Service
OAuth2：Open Authorizaion
OIDC：OpenID Connect
SAML：Security Assertion Markup Language

在介绍以上四种实现方式前，需要先知道以下三个核心概念：

身份提供商 (Identity Provider, IdP): 负责验证用户身份的系统。当用户尝试访问某个应用程序时，该应用程序会将用户重定向到 IdP 进行身份验证。
服务提供商 (Service Provider, SP): 用户尝试访问的应用程序或网站。SP 依赖于 IdP 来验证用户的身份。
信任关系: SP 和 IdP 之间需要建立信任关系，以便 SP 可以信任 IdP 提供的身份验证结果。

3.1. CAS

CAS 是一个被广泛应用的 SSO 系统，最初由耶鲁大学于 2000-2002 年研发，主要目的是为 Web 应用提供一种标准化的单点登录方案。

2004 年，耶鲁大学在 Jasig（即后来的 Apereo）的监督下将代码开源。

当用户（Web 浏览器）访问 CAS 客户端（Web 应用）时，CAS 客户端会将用户浏览器重定向到 CAS 服务器，用户在 CAS 服务器上进行身份验证（如，用户名密码认证），身份验证通过后 CAS 服务器会再次将用户重定向到 CAS 客户端（携带参数 Service Ticket），CAS 客户端发送 Service Ticket 和自己的服务标识请求 CAS 服务器获取用户信息。

CAS 单点登录的流程如下图所示：

流程详细说明：

CAS 客户端以 Filter（过滤器）方式保护 Web 应用的受保护资源，过滤从客户端过来的每个请求，同时 CAS 客户端会分析 HTTP 请求中是否包含认证 Ticket，如果没有，则说明用户没有经过认证；
CAS 客户端重定向用户请求到 CAS 服务器，这里需要提交一个 Service 参数（如 helloservice）用于指定身份验证通过后重定向的目标地址（即 CAS 客户端应用地址），如 https://casserver/login?service=https%3A%2F%2Fhelloservice；
用户认证过程：如果用户提供了正确的凭据，服务器会生产一个随机的认证 Ticket（即 Service Ticket），并缓存此 Ticket；
服务器重定向用户到 CAS 客户端并且附带刚才产生的认证 Ticket 和自己的服务标识；
CAS 客户端将用户的 Ticket 向服务端发起身份确认；
CAS 服务器通过 Ticket 确认用户认证并返回用户的信息（如用户名）。

注意点：

Ticket 只能使用一次；
Ticket 有效期要短（10s~300s）；
Ticket 创建采用安全随机数，防止被猜测；
CAS 服务器要对 service 中的 URL 进行过滤，避免跳转到恶意网站。（Apereo CAS 官方文档中也明确强调）

3.2. OAuth2.0

OAuth 是一种常用的授权框架，使网站和 web 应用程序能够请求对另一个应用程序上的用户账户的有限访问。OAuth 允许用户在不向请求的应用程序公开其登录凭据的情况下授予此访问权限。这意味着用户可以调整他们想要共享的数据，而不必将其账户的完全控制权交给第三方。

OAuth 2.0 和 OAuth 1.0 都是授权框架，用于允许第三方应用访问用户资源，但它们在实现细节和设计理念上存在显著差异。OAuth 1.0 由于存在安全问题基本已经被废弃，很少再使用。

OAuth 2.0 核心的步骤之一是让应用从授权中心获取访问令牌（Access Token），由于 OAuth2.0 的设计较为复杂，本文不会详细展开，感兴趣的读者可以关注我，博主在后期会用通俗易懂的语言结合实际案例给大家讲透彻 OAuth 2.0 的工作机制及其安全性分析。

3.3. OIDC

OAuth 2.0 本身主要用于授权（允许第三方应用访问你的资源，但不直接证明你是谁），OIDC（OpenID Connect）是在 OAuth2.0 的基础上增加了身份认证（明确用户身份）功能，所以OIDC 具备了身份认证和授权两种功能，是实现单点登录更加标准的方式。

OIDC 是一个成熟、开放的标准（由 OpenID 基金会管理），被广泛采用和支持。各种语言、框架、云服务和 IdP 都有成熟的库和实现。

关于 OIDC 协议的工作机制将会在后期博文中详细展开，这里大家只要记住 OIDC 并不是一个独立的协议，而是构建在广泛使用的 OAuth 2.0 授权框架之上的一个身份认证层。

OIDC 通过巧妙地扩展 OAuth 2.0，提供了一个强大、安全且现代化的标准，专门用于实现身份认证和单点登录。其基于 JSON/JWT 的设计、良好的安全模型、广泛的行业支持以及对各种应用类型的适应性，使其成为构建现代 Web、移动和企业应用 SSO 解决方案的首选协议。

不论是社交媒体登录(如 Facebook、Twitter)还是构建企业内部统一的身份认证平台，OIDC 都是核心的支撑技术。

3.4. SAML

SAML 是一种基于 XML 的数据标准，用于交换认证和授权信息。在单点登录场景中，SAML 主要用于在身份提供商（IdP）和服务提供商（SP）之间交换信息。

SAML 是企业级单点登录的基石协议，通过标准化 XML 断言和信任链实现安全身份联合。尽管在移动互联网时代逐渐被 OIDC 取代，但在传统企业集成、政府、教育等领域仍是不可替代的解决方案。理解其核心流程（SP → IdP → SP）和关键组件（断言、元数据、签名），是掌握企业身份治理的重要一环。

特性	SAML	OIDC
协议基础	XML/SOAP	JSON/REST (基于 OAuth 2.0)
令牌格式	XML 断言	JWT (ID Token)
主要场景	企业级 SSO（B2B、内部系统集成）	现代应用、移动端、消费者身份认证
传输效率	消息体积大（XML 冗余）	轻量级（JSON 精简）
移动端支持	弱（依赖浏览器重定向）	原生支持（适用 App 嵌入浏览器）
灵活性	配置复杂（需处理 XML 签名/加密）	开发便捷（标准 JWT 库广泛支持）
委托授权	不支持（仅认证）	支持（可结合 OAuth 2.0 访问 API）