SSO 单点登录：为什么一次登录能访问多个系统

资料 在讲 SSO 前，先回到普通登录认证机制：用户登录成功后，服务器把用户登录信息写入 Session，并为用户生成一个 Cookie 返回浏览器。用户再次访问这个系统时，请求会带上 Cookie，服务端根据 Cookie 找到对应 Session，再判断用户是否已经登录。

这个机制在单个系统里很好理解。问题出在多系统场景。一个公司可能有后台管理系统、工单系统、报表系统、知识库、采购系统，每个系统如果都维护自己的登录页、账号密码和 Session，用户就要反复登录。

反复登录不只是体验差。用户为了省事，可能在多个系统里复用同一套密码；开发团队也要在每个系统里重复实现登录、密码校验、找回密码、权限接入、登录审计。系统越多，这些重复成本越明显。

SSO 是 Single Sign-On，中文通常叫单点登录。相关的解释很直白：用户一次登录后，可以访问多个关联应用或服务，不需要再次输入凭据。它把“认证用户是谁”这件事集中交给统一认证中心处理。

业务系统不再各自校验用户密码。用户访问系统 A，系统 A 发现用户未登录，就把用户重定向到统一认证中心。认证中心让用户输入账号密码，校验成功后建立自己的登录态，并给系统 A 一个可信的登录结果。

之后用户再访问系统 B、系统 C，业务系统仍然会跳到认证中心检查。区别是认证中心已经知道这个用户登录过了，所以不再要求输入密码，而是直接给业务系统一个新的凭证。这样用户感觉就是“一次登录，到处可用”。

以访问系统 A 为例。用户打开系统 A 的页面，系统 A 发现本地没有登录态，于是把浏览器重定向到 SSO 认证中心，并带上一个回调地址，比如用户登录后要回到系统 A 的哪个页面。

用户在认证中心输入账号密码。认证中心校验通过后，建立 SSO 自己的登录态，通常也会通过 Cookie 保存认证中心域名下的会话。然后认证中心生成一个短期有效的票据，比如 ticket 或 code，把浏览器重定向回系统 A。

系统 A 拿到票据后，一般不会只相信浏览器带来的参数，而是从服务端向 SSO 认证中心校验票据。认证中心确认票据有效后，返回用户身份信息。系统 A 再创建自己的本地 Session/Cookie。到这里，用户在系统 A 中才算登录完成。

很多人第一次看 SSO 会疑惑：既然有统一认证中心，业务系统为什么还要自己的 Session？原因很简单，认证中心负责证明“这个用户已经通过认证”，业务系统还要维护“这个用户在本系统里的访问状态”。

系统 A 可能要记录用户在 A 里的权限、菜单、临时操作、当前租户、个性化配置；系统 B 也有自己的权限和业务上下文。统一认证中心不适合把所有系统里的细节状态都塞在一起管理。

所以更常见的结构是两层会话：认证中心有一份 SSO 登录态，各业务系统各自有本地登录态。用户第一次访问某系统时，需要经过 SSO 票据交换；交换成功后，后续访问该系统就靠本地 Session 判断，不必每次都去认证中心。

用户已经登录系统 A 后，再打开系统 B。系统 B 发现自己这里没有本地登录态，也会把浏览器重定向到 SSO 认证中心。认证中心检查自己的 Cookie，发现用户已经在认证中心登录过，于是不用再展示登录页。

认证中心会为系统 B 生成一张新的票据，再把浏览器带回系统 B。系统 B 从服务端校验票据，校验通过后建立系统 B 自己的 Session。对用户来说，整个过程可能只是页面跳了一下，甚至几乎无感。

这就是 SSO 的关键体验：不是所有系统共享同一个 Cookie，也不是系统 B 直接读取系统 A 的 Session，而是它们都信任同一个认证中心。认证中心负责登录入口，业务系统负责拿到可信结果后建立自己的会话。

SSO 看起来方便，但实现时要很谨慎。首先，票据必须短有效期。一个 ticket 或 code 只应该在很短时间内有效，防止被截获后长期使用。其次，票据最好只能使用一次，业务系统校验成功后，认证中心就让它失效。

回调地址也要做白名单。系统 A 跳到认证中心时会带 returnUrl，认证中心登录后再跳回去。如果不限制回调地址，攻击者可能把用户引到伪造站点，造成开放重定向风险。SSO 里所有登录、跳转、票据传输都应该走 HTTPS。

退出登录也要认真处理。只清掉业务系统 A 的 Session，用户可能访问系统 B 仍然是登录状态；只清掉认证中心会话，已经建立的业务系统本地 Session 也可能继续有效。完整退出通常要同时考虑认证中心会话和各业务系统会话。

文中列了 SSO 的三个优点。第一是降低密码复用风险。用户只需要在统一入口输入凭据，不必在多个系统里重复维护密码，也减少了多个系统各自处理密码带来的风险面。

第二是体验更方便。用户一次登录后，可以在多个关联应用之间切换，不用每进一个系统就输入账号密码。对企业内部系统来说，这一点很实在，尤其是每天要在多个平台之间来回操作的人。

第三是简化应用开发。业务系统不必重复实现完整认证流程，而是接入统一认证中心。账号体系、登录审计、多因素认证、密码策略、账号冻结等能力可以集中建设，业务系统只负责接收认证结果和处理本系统授权。

SSO 是目标，不是某一个固定协议。CAS、SAML、OAuth 2.0、OpenID Connect 都可以用来实现单点登录场景。它们在术语、票据格式、令牌交换和适用范围上不同，但共同点都是把认证从业务系统里抽出来，交给可信的认证方。

JWT 也经常出现在 SSO 讨论里。它可以作为令牌格式，携带用户身份和一些声明，业务系统通过签名校验判断令牌是否可信。但 JWT 不等于 SSO，本身也不自动解决登录跳转、会话管理、退出登录和权限同步。

学习阶段可以先不急着陷进协议细节。先把角色分清：用户浏览器负责跳转和携带 Cookie，业务系统负责保护自己的资源和建立本地会话，认证中心负责账号校验和签发可信凭证。这个骨架稳了，再看具体协议会容易很多。

SSO 出问题时，先看跳转链路。用户从业务系统跳到认证中心时，returnUrl 是否正确；认证中心登录后是否带票据跳回业务系统；业务系统有没有拿票据去服务端校验；校验通过后有没有创建本地 Session。

如果表现是反复跳登录页，要看 Cookie 是否被浏览器保存和发送，域名、SameSite、Secure、HTTPS、跨域嵌入是否影响了认证中心会话。也要看系统时间是否一致，因为票据短有效期对时间偏差很敏感。

如果表现是某个系统能登录、另一个系统不能登录，就重点看该系统在认证中心的配置：应用 ID、密钥、回调地址白名单、票据校验接口、用户映射、权限同步。SSO 是多方协作，任何一方配置错，都会表现成登录异常。

如果被问什么是 SSO，可以先说：SSO 是单点登录，用户在统一认证中心完成一次登录后，可以访问多个关联业务系统，不需要在每个系统重复输入账号密码。

然后讲流程：用户访问业务系统，业务系统发现未登录，把浏览器重定向到认证中心；认证中心校验用户身份后签发票据并跳回业务系统；业务系统向认证中心校验票据，确认用户身份后建立自己的本地 Session。用户再访问其他系统时，认证中心已有登录态，可以直接签发新的票据。

最后补优点和安全点：SSO 能减少重复登录、降低密码复用风险、简化应用开发；实现时要注意票据短有效期、一次性使用、回调地址白名单、HTTPS 传输，以及退出登录时清理认证中心和各业务系统会话。