单点登录（SSO）

作为前端开发，我们经常会遇到这样的场景：公司有多个业务系统 —— 官网、后台管理系统、客户中心、数据分析平台，用户登录其中一个系统后，再访问其他系统时不需要重复输入账号密码。这种 “一次登录，处处通行” 的能力，就是单点登录（Single Sign On，简称 SSO）要解决的核心问题。

本文将从核心概念、实现原理、主流方案、前端对接要点四个维度，彻底讲透单点登录。

一、为什么需要单点登录？

在没有 SSO 的系统架构中，多系统登录存在三个致命问题：

用户体验差：每个系统都需要单独登录，记住多套账号密码；
开发维护成本高：每个系统都要开发一套登录、鉴权逻辑，重复造轮子；
安全风险高：多系统的账号体系分散，密码管理混乱，容易出现安全漏洞。

而单点登录的核心价值，就是在多个相互信任的系统中，用户只需一次身份验证，即可访问所有授权系统，同时降低开发和安全成本。

二、单点登录的核心概念与原理

1. 核心角色

要理解 SSO，首先要明确三个核心角色：

用户：发起登录请求的终端使用者；
服务提供方（SP）：需要用户登录才能访问的业务系统（如公司的后台管理系统、客户中心）；
身份提供方（IdP）：统一管理用户身份的认证中心（如企业的统一账号平台、OAuth2.0 的授权服务器）。

2. 核心原理

单点登录的本质是“身份凭证的跨系统共享与验证”，核心逻辑可以概括为三句话：

用户在IdP 认证中心完成首次登录，IdP 生成一个可信的身份凭证（如 Token、票据）；
用户访问其他SP 业务系统时，SP 会重定向用户到 IdP 验证身份；
IdP 验证用户的身份凭证有效后，告知 SP “该用户已登录”，SP 直接放行，无需用户重复登录。

这里的关键是“身份凭证的安全性”和“跨域传递的可靠性”—— 凭证必须是加密的、防篡改的，且能在不同域名的系统间传递。

三、单点登录的主流实现方案

根据不同的技术架构和场景，单点登录有多种实现方案，其中最常用的是Cookie+Session 方案和Token 方案（基于 JWT），还有标准化的OAuth2.0/OIDC 方案。

方案 1：基于 Cookie+Session 的 SSO（传统方案）

这种方案是单点登录的 “鼻祖”，适用于同域名下的多子系统（如a.company.com、b.company.com），核心依赖父域名 Cookie 的跨域共享。

实现流程

用户首次访问 SP 系统
- 用户访问a.company.com（SP1），系统检测到用户未登录，重定向到统一认证中心sso.company.com（IdP）；
- 用户在 IdP 输入账号密码，IdP 验证通过后，创建一个全局 Session（存储用户身份信息），并生成一个全局 SessionID；
- IdP 将全局 SessionID 写入父域名 Cookie（domain=.company.com），然后重定向回 SP1；
- SP1 读取父域名 Cookie 中的 SessionID，向 IdP 发起请求验证 SessionID 有效性；
- IdP 返回用户身份信息，SP1 创建本地 Session，用户成功登录。
用户访问其他 SP 系统
- 用户访问b.company.com（SP2），系统检测到用户未登录，重定向到 IdP；
- IdP 读取父域名 Cookie 中的 SessionID，验证有效后，直接重定向回 SP2，并携带用户身份信息；
- SP2 创建本地 Session，用户无需登录即可访问。

优缺点

优点：实现简单，依赖浏览器 Cookie 机制，无需额外开发；
缺点：仅支持同父域名的系统，跨主域名（如companyA.com和companyB.com）无法使用；Session 存储在服务端，分布式部署时需要 Session 共享（如 Redis）。

方案 2：基于 Token 的 SSO（现代方案，推荐）

这种方案是目前前后端分离架构的主流选择，核心依赖无状态的 Token（如 JWT），支持跨域名、跨平台的系统集成。

核心载体：JWT（JSON Web Token）

JWT 是一种轻量级的身份凭证，由三部分组成：

Header：声明加密算法和 Token 类型；
Payload：存储用户身份信息（如用户 ID、角色、过期时间）；
Signature：使用密钥对 Header 和 Payload 加密，防止篡改。

JWT 的特点是无状态—— 服务端不需要存储 Session，只需通过密钥验证 Signature 的有效性即可。

实现流程

用户首次登录 IdP
- 用户访问任意 SP 系统，未登录则重定向到 IdP；
- 用户输入账号密码，IdP 验证通过后，生成JWT Token；
- IdP 将 JWT Token 返回给用户，可以通过 URL 参数、Cookie 或 LocalStorage 存储。
用户访问其他 SP 系统
- 用户访问其他 SP 系统时，前端将 JWT Token 携带在请求头（如Authorization: Bearer <token>）中；
- SP 系统收到请求后，提取 JWT Token，使用共享密钥验证 Token 的有效性和合法性；
- 验证通过后，解析 Token 中的用户信息，直接放行。

优缺点

优点：支持跨域名、跨平台（Web、小程序、APP）；无状态，服务端无需存储 Session，易于分布式部署；
缺点：Token 一旦生成无法主动作废（除非设置很短的过期时间，配合刷新 Token 机制）；Payload 不能存储敏感信息（因为 Base64 编码可解码）。

方案 3：基于 OAuth2.0/OIDC 的 SSO（标准化方案）

OAuth2.0 是一个授权协议，本身不是为单点登录设计的，但可以通过扩展实现 SSO；而 OIDC（OpenID Connect）是基于 OAuth2.0 的身份认证协议，专门解决单点登录问题。

这种方案适用于第三方系统集成的场景，比如 “使用微信账号登录第三方网站”“使用企业微信账号登录公司内部系统”。

核心流程（以 OAuth2.0 的授权码模式为例）

用户访问 SP 系统，选择 “使用 XX 账号登录”，SP 重定向到 IdP 的授权页面；
用户在 IdP 授权页面确认授权，IdP 生成一个授权码，重定向回 SP；
SP 使用授权码向 IdP 请求访问令牌（Access Token）；
IdP 返回 Access Token，SP 使用 Access Token 获取用户身份信息；
SP 完成用户登录，后续访问其他系统时重复上述流程。

典型应用

微信开放平台、支付宝开放平台的第三方登录；
企业内部的统一身份认证（如基于钉钉、飞书的 SSO）。

四、前端对接单点登录的核心要点

作为前端开发者，在对接 SSO 系统时，需要关注以下 4 个关键细节：

1. 重定向逻辑处理

当用户访问需要登录的页面时，前端需要检测用户是否已持有有效凭证（如 JWT Token）：

若无凭证：跳转到 IdP 的登录页面，并携带回调地址（登录成功后返回原页面）；
若有凭证：直接请求数据。

示例代码（Vue 项目）：

// 路由守卫 router.beforeEach((to, from, next) => { const token = localStorage.getItem('sso_token'); // 需要登录的页面 if (to.meta.requiresAuth) { if (token) { next(); } else { // 重定向到IdP登录页面，携带回调地址 const redirectUrl = encodeURIComponent(window.location.href); window.location.href = `https://sso.company.com/login?redirect=${redirectUrl}`; } } else { next(); } });

2. 凭证的存储与传递

存储方式：
- Cookie：自动携带跨域请求，但需注意跨域 Cookie 的配置（SameSite=None; Secure）；
- LocalStorage：无法自动携带，需手动在请求头中添加；
- SessionStorage：仅在当前会话有效，关闭浏览器后失效。
传递方式：
- 接口请求：在请求头中添加Authorization: Bearer <token>；
- 页面跳转：通过 URL 参数传递（注意 URL 长度限制和安全性）。