SSO 单点登录：原理、技术与案例

现代很多公司内网系统都是类似这样的体验：登录一次 OA 系统后，打开邮箱、CRM、代码仓库，不用给每个系统反复输密码。这背后的功臣，就是 SSO（Single Sign-On，单点登录）。

公司的一套商用系统，包括一个客户网站，一个业务网站，一个后台客户系统，一个后台管理员系统，要求也实现单点登录。全程我一个人完成，我们的系统集成了Microsoft Azure B2C来做认证和授权。我在做这个工作过程中，做了不少调研和相关知识的了解，这里总结一篇文章，简单讲讲 SSO 的原理、主流技术方案（CAS / SAML / OAuth 2.0 / OIDC）、以及真实应用场景。

一、什么是 SSO？

单点登录指的是：用户只需要登录一次，就可以访问多个相互信任的应用系统，而不需要在每个系统里重复输入账号密码。

它要解决的核心矛盾是：

• 现代企业往往有多个系统（OA、CRM、代码平台、监控平台……）
• 每个系统都要求登录，用户体验极差，密码也难以统一管理
• 安全团队也很痛苦：账号权限分散在各处，员工离职时很难做到"一键收权"

SSO 的目标就是把"认证"这件事，从每个业务系统里剥离出来，交给一个统一的 身份提供方（IdP，Identity Provider） 去做。

二、SSO 的核心原理

无论具体用哪种协议，SSO 的底层逻辑都可以归纳为一句话：

由一个中心化的"身份提供方"完成认证，并向各个"服务提供方"签发一个可验证的凭证，服务方信任这个凭证，从而免去重复登录。

拆解一下这句话里的几个关键角色：

典型登录流程（以最常见的重定向模式为例）

关键点在第 6～10 步：票据只在 IdP 和 SP 之间传递校验，用户的密码从始至终只出现在 IdP 一处，这也是 SSO 比"账号密码同步"更安全的根本原因。

之后用户再访问系统 B、系统 C 时，由于浏览器里已经有 IdP 种下的登录态（Cookie），会直接跳过第 4～5 步的登录页面，实现"无感"跳转。

三、主流技术方案对比

SSO 不是某一个具体协议，而是一类问题的统称。业界针对不同场景演化出了几套主流技术方案。

1. Cookie + 域名共享（早期方案）

如果所有子系统都在同一个主域名下（如 a.company.com、b.company.com），可以直接把登录 Cookie 的 Domain 设置成 .company.com，让所有子域共享同一个 Cookie。

• 优点：实现简单，不需要额外协议
• 缺点：只能解决同域场景，跨域（比如对接第三方系统）完全无能为力，现在很少单独使用

2. CAS（Central Authentication Service）

CAS 是经典的企业级 SSO 协议，上面时序图画的就是 CAS 的标准流程（Ticket 模式）。

• 核心概念：TGT（登录中心的会话票据）+ ST（Service Ticket，一次性服务票据）
• 特点：协议简单、开源实现成熟（Apereo CAS），非常适合企业内部系统之间的互信登录
• 局限：主要面向 Web 场景，对移动端、API 场景支持较弱

3. SAML 2.0（Security Assertion Markup Language）

SAML 用 XML 格式的"断言（Assertion）"来传递身份信息，是大型企业、政府、金融行业跨组织单点登录的事实标准。

• 典型场景：企业员工用公司账号登录 Salesforce、Workday 等 SaaS 服务
• 特点：安全性高、断言可以携带丰富的属性信息，但 XML 结构冗长，实现和调试成本较高

4. OAuth 2.0（授权框架，非纯粹的登录协议）

严格来说 OAuth 2.0 解决的是"授权"问题（我允许 A 应用访问我在 B 平台的数据），而不是"认证"问题。但由于其流程与 SSO 高度相似，早期很多系统"借用"OAuth 2.0 来做登录，这也是历史上产生大量安全漏洞的原因之一。

5. OIDC（OpenID Connect）—— 现代 SSO 的主流选择

OIDC 是在 OAuth 2.0 授权框架之上，加了一层标准化的身份层，专门用来解决"登录认证"问题。可以理解为：

OIDC = OAuth 2.0（负责拿到访问令牌）+ ID Token（负责证明你是谁）

• 核心产物：ID Token，一个标准的 JWT（JSON Web Token），里面包含用户身份信息，且自带签名可供 SP 验证
• 目前几乎所有"使用 Google/微信/GitHub 账号登录"的场景，底层都是 OIDC
• 生态成熟：Auth0、Keycloak、Azure AD、Okta 等主流身份平台都以 OIDC 为核心协议

技术方案对比一览

对于我们公司的商用系统，自然选择OIDC。

四、JWT：贯穿现代 SSO 的技术基石

无论是 OIDC 的 ID Token，还是很多自研 SSO 系统的登录票据，现在几乎都用 JWT 来承载身份信息。它由三段 Base64 编码的字符串组成：

header.payload.signature

# header：声明算法类型，如 HS256 / RS256
# payload：携带用户身份信息（sub、name、exp 过期时间等）
# signature：用密钥对前两段签名，保证内容未被篡改

JWT 的最大价值在于无状态校验：SP 系统本地拿到 JWT 后，用约定好的公钥/密钥验证签名即可确认身份，不需要每次都回源到 IdP 查询，大幅降低了系统间的耦合和网络开销。当然，这也带来一个经典权衡——JWT 一旦签发，在过期之前很难主动"吊销"，所以生产环境通常会搭配较短的过期时间 + 刷新令牌（Refresh Token）机制。

五、真实应用案例

1. 企业内部办公系统 员工用统一的域账号（AD/LDAP）登录一次，即可访问 OA、邮箱、内部 Wiki、监控后台等系统，这是 CAS/SAML 最经典的落地场景。

2. 消费级"第三方登录" 打开一个新 App，点击"使用微信登录"或"Sign in with Google"，几秒钟完成注册登录——这背后就是标准的 OIDC 授权码流程。

3. 企业级 SaaS 集成（B2B） 企业采购了 Salesforce、飞书、Zoom 等一堆 SaaS 服务后，往往会部署 Okta / Azure AD 这类身份平台作为统一的 IdP，通过 SAML 或 OIDC 把所有 SaaS 服务"串"起来，员工一处登录，处处可用。

4. 微服务网关统一鉴权 在微服务架构下，网关层（Gateway）统一校验 JWT，验证通过后再把请求转发给后端服务，各微服务本身不需要重复处理登录逻辑，这也是 SSO 思想在系统架构层面的延伸。

六、小结

SSO 本质上是把"认证"这件事从业务系统中解耦出来，交给一个专门、可信的中心去做。理解它的关键，不在于死记某个协议的报文格式，而在于抓住这条主线：

谁来验证身份 → 颁发什么样的凭证 → 凭证如何被其他系统信任和校验