在企业里上班的人对这样的早晨很熟悉：早上到岗，登录一次办公门户，随后点开邮箱、CRM、报销系统，全都直接进入，没有再输过一次密码。这就是单点登录在干活。反过来，如果没有它，八个系统八套密码，员工疲于记忆，管理员疲于删号——密码一多，弱密码和便签纸密码必然泛滥。
SSO（Single Sign-On，单点登录）是一种身份认证机制：用户只需登录一次，即可访问多个相互信任的应用系统。本文讲清它的核心角色与工作流程、四大协议的选型对比、令牌的内部结构，以及收益背后的代价。
1、SSO 要解决什么
密码认证本身很简单，难的是规模。一个组织内部几十个系统，各自记账各自认证，会同时制造三个问题：用户体验割裂，每换一个系统就登录一次；安全面扩大，密码存得越多、泄露得越多；管理成本高，入职要开几十个账号，离职要逐个回收，漏一个就是隐患。
SSO 的解法是把认证从各个系统里抽出来，交给一个中央服务统一做。两个核心角色由此登场，分工如下：
| 角色 | 全称 | 职责 |
|---|---|---|
| IdP | Identity Provider（身份提供方） | 验证用户身份，签发凭证 |
| SP | Service Provider（服务提供方） | 业务系统本身，信任 IdP 的结论 |
认证这件事从此只发生在 IdP 一处：各系统不再碰密码，只认 IdP 发的凭证。用户登录一次、处处通行，管理员删号一处、处处失效——三个规模问题一次解决。
2、一次登录的完整流程
2.1、首次登录
用户访问系统 A，系统 A 发现本地没有登录态，把浏览器重定向到认证中心，并带上自己的回调地址。用户在认证中心的页面上输入账号密码，验证通过后，认证中心签发一张凭证（Token 或 Ticket），随重定向送回系统 A 的回调地址；系统 A 拿凭证向认证中心验证（或本地校验签名），确认有效后建立本地会话，放行用户。整个首次登录的时序如下：
图中的关键设计是浏览器在中间跑腿：凭证经由浏览器带回系统 A，而验证与身份确认发生在系统 A 与 IdP 之间（或通过签名本地完成）——两段路径各司其职。
2.2、免登访问
之后用户访问系统 B：系统 B 同样把他重定向到认证中心，但这次认证中心发现浏览器里已有自己的全局会话（首次登录时种下的 Cookie），不再要求输密码，直接签发给系统 B 的凭证并弹回。于是用户看到的体验是页面闪一下就登录了。"登录一次"的本质，是 IdP 自己的会话还活着；它在，每个新系统都只是走一遍免密重定向。
2.3、登出为什么麻烦
登录统一了，登出却常常没跟上。严格的单点登出要求 IdP 通知所有已登录的系统销毁会话，任何一家通知失败就留下残存活会话；很多实现只销毁 IdP 自己的会话，各系统的本地会话要等自然过期。集成 SSO 时，"注销到底注销了什么"必须在设计阶段问清楚，这是审计场景的高频考点。
3、四大协议对比
SSO 是思想，落地靠协议。主流的四种各有领地：
| 协议 | 诞生 | 载体 | 定位 |
|---|---|---|---|
| CAS | 耶鲁大学，2001 年前后 | 自定义票据 | 高校与传统企业内网 |
| SAML 2.0 | OASIS 标准，2005 年 | XML | 大型企业与政府应用 |
| OAuth 2.0 | IETF，RFC 6749 | HTTP 与 JSON | 授权框架 |
| OIDC | OpenID 基金会，2014 年 | JWT | OAuth 2.0 上的认证层 |
3.1、CAS 与 SAML
CAS 是最早的集中式认证协议之一，靠一张服务票据（Service Ticket）往返完成认证，协议简单、客户端接入容易，至今仍是高校图书馆、教务系统的常客，现由 Apereo 基金会维护（官方站点）。SAML 2.0 则是企业级市场的老国王：基于 XML 的断言（Assertion）携带用户属性，签名体系完备，支持联邦身份，政府、金融、大型 SAP 类系统里随处可见；代价是 XML 规范极其繁琐，调试一个签名错误可能耗掉一下午。
3.2、OAuth 2.0 与 OIDC
这里有一个流传最广的误区要先摆正：OAuth 2.0 是授权协议，不是认证协议。它解决的是"用户同意让第三方应用访问自己的资源"，回答的问题是"能不能拿数据"；而登录要回答的是"这个人是谁"。直接拿 OAuth 2.0 的访问令牌当登录用，会漏掉身份声明与签名校验，业内把这种误用叫"伪认证"。
OIDC（OpenID Connect）就是补上这一层的结果：在 OAuth 2.0 之上增加一个 ID Token——一个携带用户身份、经过签名的 JWT，专门回答"是谁"。今天"用微信登录""用 Google 账号登录"的第三方登录，绝大多数走的都是 OIDC。一次完整的授权码流程，浏览器要访问的地址长这样：
https://idp.example.com/authorize?
response_type=code&
client_id=app_123&
redirect_uri=https://app.example.com/callback&
scope=openid%20profile&
state=x7f3a
URL 里每个参数都有职责：response_type=code 声明走授权码流程；scope=openid 就是 OIDC 的标志，不带它只是普通 OAuth；state 由客户端生成并原样带回，用来防跨站请求伪造。协议细节见 OAuth 官方教程站 与 OIDC 官方文档。
4、凭证里面是什么
签发的凭证以 JWT（JSON Web Token）最为常见。它由三段组成，用点号分隔：头部（签名算法）、载荷（声明）、签名。载荷是 Base64URL 编码的 JSON，可以直接解开看：
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6Ilx1NWMwZlx1NzUzNyJ9.KxTA3...
│ │ │
头部：算法 载荷：sub 用户号、name 姓名 签名：防篡改
三段以点号分隔：头部与载荷只是编码，签名才提供保证——改一个字符，签名校验就失败。载荷解码后就是一段普通的 JSON：
{
"iss": "https://idp.example.com",
"sub": "1234567890",
"name": "张三",
"aud": "app_123",
"exp": 1932000000
}
五个字段各有含义：iss 是签发者，sub 是用户唯一标识，aud 是预期接收方，exp 是过期时间，name 是展示用的姓名。要紧的一条：载荷只是编码，不是加密——任何人都能解开看到内容，所以 JWT 里绝不能放密码、手机号这类敏感信息；防的是篡改（签名校验），不是偷看。结构细节可在 jwt.io 在线把玩验证。
5、收益与代价
SSO 的收益是明确的：用户体验上一次登录处处通行；安全上密码只交给 IdP 一处保管，业务系统不再碰密码，弱密码与撞库风险同步收敛；管理上一处注销多处生效，审计有单一权威源。
但集中是有代价的，四条都要正视：
| 代价 | 说明 | 对策 |
|---|---|---|
| 单点故障 | IdP 宕机，所有系统登不进去 | IdP 高可用部署，降级预案 |
| 攻击面集中 | 打下 IdP 等于拿下全部系统 | MFA 多因素、异常登录检测 |
| 集成成本 | 每个老系统都要改造成 SP | 逐步接入，网关层兼容 |
| 会话复杂性 | 登出语义、超时策略要统一 | 明确注销语义与超时矩阵 |
表里第二条值得展开：钓鱼与凭证填充攻击会集中瞄准 IdP 的登录页，所以现代 IdP 普遍强制多因素认证、设备指纹与异地登录风控——SSO 的安全水位，基本等于 IdP 的安全水位。
6、典型应用场景
两类场景最典型。其一是企业内部一体化办公：OA、邮箱、CRM、代码仓库、报表平台共用一个企业身份，入职开一号、离职删一号，访问审计有统一出口；其二是互联网第三方登录：用微信、Google、Apple 账号登录其他网站，把"注册-记密码-忘密码-找回"的整条链路换成一次授权跳转，也是 OIDC 的大规模实践。
选型上给一个粗线条的地图：老旧企业系统并购整合、客户指定标准，选 SAML；全新互联网应用与移动端，选 OIDC；已有 CAS 资产的高校与国企内网，继续用 CAS 不必迁移；只做"授权访问数据"不做登录，用纯 OAuth 2.0。
7、总结
回顾全文：SSO 把认证从业务系统抽到 IdP 统一处理，首次登录换取凭证、后续系统免密放行；CAS 与 SAML 守企业存量，OIDC 是当下第三方登录的主流，OAuth 2.0 本身只管授权不管认证；JWT 载荷可解码不加密，敏感信息不入令牌；收益是体验、安全与管理的三重收敛，代价是 IdP 成为必须重点设防的单点。对于正在选型的团队，建议新系统一律 OIDC 起步并强制 MFA，存量系统按集成成本排期迁移；无论走哪条路，先把"注销时到底销毁了哪些会话"写进设计文档——这是 SSO 项目上线后最常被审计追问的一个问题。
