手把手教你设计SSO 单点登录系统：从需求到落地的全方案解析

一、开篇：为什么我们需要单点登录？

想象一下这样的场景：你打开电脑开始一天的工作，先是登录 OA 系统处理请假流程，接着切换到财务系统填报报销单，然后又要登录 CRM 系统跟进客户信息…… 每进入一个新系统，都要重新输入用户名和密码，不仅繁琐耗时，还容易因为密码太多记错而耽误工作。

作为技术负责人，这时候一系列问题摆在你面前：如何保证用户在多个系统间无缝切换无需重复登录？怎样确保用户身份信息安全传输？又该如何兼容不同技术栈开发的老系统？

这些问题的答案，正是单点登录系统的核心价值所在。

二、简介：什么是单点登录（SSO）？

单点登录（Single Sign On，简称 SSO）是一种主流的企业业务整合方案，其核心机制是：用户只需一次登录，即可访问所有相互信任的应用系统。

从技术本质来看，SSO 是一种集中式身份认证机制。它通过独立的认证中心统一管理用户身份与授权信息：

1. 用户在某一应用完成登录后，认证中心生成包含身份与授权信息的令牌
2. 访问其他应用时，用户只需携带该令牌
3. 应用通过认证中心验证令牌有效性，即可完成快速登录

这种机制彻底打破了传统 "一系统一登录" 的壁垒，实现了跨应用的身份互通。

三、挑战：核心问题分析

尽管单点登录（SSO）系统架构通过实现 “一次登录，全网通行”，有效提升用户体验与管理效率。然而，在实际设计过程中，仍会面临诸多问题与挑战，具体如下：

• 跨域认证难题：多个子系统可能部署在不同域名下，浏览器的同源策略限制了 Cookie、LocalStorage 等数据的共享，导致身份信息无法互通。
• 安全与性能平衡：既要保证用户身份数据在传输和存储过程中的安全性，防止被窃取或篡改，又要确保认证流程高效，不能让用户等待太久。
• 系统兼容性：企业内部可能存在多种技术框架开发的系统，新设计的 SSO 系统需要能兼容这些老系统，避免大规模改造。

基于以上分析，我们设计一个通用 SSO 架构：

在这个架构中，SSO 认证中心是核心枢纽。它负责统一管理用户的身份认证，存储用户信息。各个应用系统与认证中心进行交互，由认证中心判断用户是否已登录，以及验证用户身份的合法性。

四、详细设计方案

在当今数字化生态中，单点登录（SSO）已成为企业级系统架构的核心需求。目前，当前主流技术方案采用OAuth 2.0/OpenID Connect 协议框架 + JWT（JSON Web Token）+ 统一认证服务的组合模式，核心设计思路包括三部分：

1. 用户身份集中认证：用户通过统一入口访问认证中心（Identity Provider, IDP），提交基础身份凭证（如用户名 / 密码、生物特征等）进行集中身份验证。
2. 令牌化身份传递：认证中心验证通过后，基于 OAuth 2.0/OpenID Connect 标准协议生成加密的 JWT 令牌，该令牌包含用户身份标识、权限范围、有效期等信息，并通过安全通道传递给客户端。
3. 无状态权限校验：用户后续访问企业内任何关联子系统时，只需在 HTTP 请求头中携带该 JWT 令牌。子系统通过预共享密钥或公钥基础设施（PKI）验证令牌签名和有效性，无需与认证中心进行实时通信。

这种架构设计不仅实现了跨系统的身份互认与单点登录，更通过 JWT 的无状态特性解决了传统会话管理的性能瓶颈，同时借助 OAuth 2.0 的授权框架为微服务架构提供了标准化的权限管理方案。在实践中，还需结合令牌刷新机制、分布式缓存和熔断策略，构建高可用、高安全的企业级身份基础设施。

1. 认证流程

SSO 的登录认证流程可概括为四个核心步骤：

• 首次访问：用户访问应用系统1，系统1 检查用户是否携带有效的Token，若没有则重定向到 SSO 认证中心。
• 登录验证：认证中心判断用户未登录，展示登录页面。用户输入用户名和密码后，认证中心验证信息，若正确则生成一个全局唯一的 Token，并将 Token 与用户信息关联存储。
• 重定向回应用：登录成功后，认证中心将 Token 通过 URL 参数传递回应用系统1，系统拿到 Token 后存储起来，并在后续请求中携带 Token 进行身份验证。
• 访问其他系统：当用户访问应用系统2 时，系统2同样检查Token，发现没有则重定向到认证中心。认证中心检测到用户已登录，直接将 Token 返回给应用系统 2，无需用户再次输入密码。

2. 系统兼容

在企业数字化建设中，系统兼容是实现 SSO 的关键一环，尤其是老系统与外采系统，需采用不同策略实现与 SSO 认证中心的融合。

老旧系统兼容：老系统通常架构陈旧、技术栈多样，全面改造成本高。因此，采用反向代理层兼容与中间件插件兼容两种方案：

• 反向代理层兼容：基于 Nginx 或 Apache 等反向代理服务器，在网络层面拦截用户请求。代理服务器检查请求中是否携带 SSO 认证中心颁发的 Token，若无 Token 则重定向至认证中心；若有 Token，则将 Token 添加到请求头，转发至老系统，实现无侵入式集成。
• 中间件插件兼容：针对反向代理无法适配的老系统，依据其技术栈开发定制插件。如 Java 系统开发 Servlet Filter 插件，PHP 系统开发 Middleware 中间件，在应用层面拦截请求，处理 Token 验证与用户身份信息传递，实现深度集成。

外采系统适配：在企业数字化建设中，常会引入外部采购的非自研系统。这些系统若无法直接融入企业现有单点登录（SSO）体系，会增加用户操作复杂度与管理成本。为此，可通过以下三种方式实现非自研系统的单点登录功能：

• 标准协议对接：外采系统支持 OAuth 2.0、OpenID Connect 等标准协议时，直接对接 SSO 认证中心，配置参数后即可快速集成。
• 反向代理接入：若系统不支持标准协议，利用 Nginx 等反向代理服务器拦截请求，按需重定向或转发 Token 完成校验。
• 联合开发适配：与供应商协作，通过开放接口或修改认证模块，定制适配插件，并同步用户权限体系。

五、案例分享

某大型制造业公司，业务涵盖生产制造、供应链管理、销售与客户服务等多个领域，拥有数十个不同类型的 IT 信息化系统，包括 ERP（企业资源计划）、MES（制造执行系统）、CRM（客户关系管理系统）、OA（办公自动化系统）等。

随着业务的扩张和系统数量的增加，员工需要在不同系统间频繁切换登录，不仅效率低下，还存在账号密码管理混乱、信息安全风险高等问题。为解决这些痛点，该公司决定构建 SSO 单点登录架构。

技术方案：采用 CAS 作为认证中心，支持多种标准协议；老系统通过 Nginx 反向代理兼容，外采系统依是否支持标准协议分别对接；安全上采用 HTTPS 加密、JWT Token、多因素认证等措施。整体架构图如下：

实施效果：员工一次登录即可访问所有授权系统，提升效率；统一安全措施降低风险；集中管理优化 IT 部门效率，为数字化转型提供支撑。

总结

设计单点登录系统的核心目标是解决三大问题：跨域认证、安全与性能平衡、系统兼容性。通过构建以 SSO 认证中心为核心的架构，结合标准化认证流程（如 OAuth 2.0+JWT）、严格的安全措施及灵活的兼容方案，可搭建出高效、安全的 SSO 体系。