肇庆市网站建设_网站建设公司_Vue_seo优化
2026/1/21 23:59:32 网站建设 项目流程

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

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

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

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

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

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

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

1. 核心角色

要理解 SSO,首先要明确三个核心角色:

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

2. 核心原理

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

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

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

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

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

方案 1:基于 Cookie+Session 的 SSO(传统方案)

这种方案是单点登录的 “鼻祖”,适用于同域名下的多子系统(如a.company.comb.company.com),核心依赖父域名 Cookie 的跨域共享

实现流程
  1. 用户首次访问 SP 系统

    • 用户访问a.company.com(SP1),系统检测到用户未登录,重定向到统一认证中心sso.company.com(IdP);
    • 用户在 IdP 输入账号密码,IdP 验证通过后,创建一个全局 Session(存储用户身份信息),并生成一个全局 SessionID
    • IdP 将全局 SessionID 写入父域名 Cookiedomain=.company.com),然后重定向回 SP1;
    • SP1 读取父域名 Cookie 中的 SessionID,向 IdP 发起请求验证 SessionID 有效性;
    • IdP 返回用户身份信息,SP1 创建本地 Session,用户成功登录。
  2. 用户访问其他 SP 系统

    • 用户访问b.company.com(SP2),系统检测到用户未登录,重定向到 IdP;
    • IdP 读取父域名 Cookie 中的 SessionID,验证有效后,直接重定向回 SP2,并携带用户身份信息;
    • SP2 创建本地 Session,用户无需登录即可访问。
优缺点
  • 优点:实现简单,依赖浏览器 Cookie 机制,无需额外开发;
  • 缺点:仅支持同父域名的系统,跨主域名(如companyA.comcompanyB.com)无法使用;Session 存储在服务端,分布式部署时需要 Session 共享(如 Redis)。

方案 2:基于 Token 的 SSO(现代方案,推荐)

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

核心载体:JWT(JSON Web Token)

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

  • Header:声明加密算法和 Token 类型;
  • Payload:存储用户身份信息(如用户 ID、角色、过期时间);
  • Signature:使用密钥对 Header 和 Payload 加密,防止篡改。

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

实现流程
  1. 用户首次登录 IdP

    • 用户访问任意 SP 系统,未登录则重定向到 IdP;
    • 用户输入账号密码,IdP 验证通过后,生成JWT Token
    • IdP 将 JWT Token 返回给用户,可以通过 URL 参数、Cookie 或 LocalStorage 存储。
  2. 用户访问其他 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 的授权码模式为例)
  1. 用户访问 SP 系统,选择 “使用 XX 账号登录”,SP 重定向到 IdP 的授权页面;
  2. 用户在 IdP 授权页面确认授权,IdP 生成一个授权码,重定向回 SP;
  3. SP 使用授权码向 IdP 请求访问令牌(Access Token)
  4. IdP 返回 Access Token,SP 使用 Access Token 获取用户身份信息;
  5. SP 完成用户登录,后续访问其他系统时重复上述流程。
典型应用
  • 微信开放平台、支付宝开放平台的第三方登录;
  • 企业内部的统一身份认证(如基于钉钉、飞书的 SSO)。

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

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

1. 重定向逻辑处理

当用户访问需要登录的页面时,前端需要检测用户是否已持有有效凭证(如 JWT Token):

  • 若无凭证:跳转到 IdP 的登录页面,并携带回调地址(登录成功后返回原页面);
  • 若有凭证:直接请求数据。

示例代码(Vue 项目):

js

// 路由守卫 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 长度限制和安全性)。

3. 跨域问题处理

当 SP 系统和 IdP 系统跨域名时,会存在跨域问题,解决方案:

  • 后端配置CORS(允许 SP 域名的跨域请求);
  • 使用JSONP(仅支持 GET 请求);
  • 采用授权码模式(通过重定向传递数据,避开 AJAX 跨域限制)。

4. 登出逻辑处理

单点登录的登出需要全局登出—— 用户在任意系统登出后,所有系统都需要同步登出:

  1. 用户在 SP 系统点击登出,前端清除本地存储的 Token;
  2. 前端跳转到 IdP 的全局登出接口,IdP 清除全局的身份凭证;
  3. IdP 重定向到各个 SP 系统的登出接口,清除本地 Session/Token。

五、单点登录的安全注意事项

  1. 凭证加密:Token 或 SessionID 必须加密传输,采用 HTTPS 协议,防止被中间人劫持;
  2. 凭证过期:设置合理的过期时间,JWT Token 建议不超过 2 小时,配合刷新 Token 机制;
  3. 防 CSRF 攻击:使用 Cookie 存储凭证时,开启SameSite属性,同时验证请求的 Referer 或 Origin;
  4. 防 XSS 攻击:避免将 Token 存储在 LocalStorage(容易被 XSS 攻击窃取),优先使用 HttpOnly Cookie;
  5. 幂等性处理:IdP 的回调接口要保证幂等性,防止重复创建用户 Session。

六、总结

单点登录的核心是 **“一次认证,多系统共享”**,不同方案适用于不同场景:

  • 同域名多系统 → 选择Cookie+Session 方案
  • 前后端分离、跨域名多系统 → 选择JWT Token 方案
  • 第三方系统集成 → 选择OAuth2.0/OIDC 方案

作为前端开发,掌握单点登录的原理和对接方式,能帮助我们更好地应对复杂的系统集成场景,提升用户体验。

👉 **觉得有用的点点关注谢谢~**

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询