SSO（单点登录）完全指南

SSO（单点登录）完全指南 — 一次登录畅通所有应用的技术原理

核心摘要：SSO（Single Sign-On，单点登录）是一种只需一次认证即可自动访问多个服务的身份验证机制。对企业而言，SSO 能同时实现提升员工效率、强化信息安全、降低 IT 管理成本三大目标，是不可或缺的基础设施。本文将从 SSO 的工作原理、主流协议对比到部署实施清单，以通俗易懂的方式为您逐一解读。

每天到公司，您做的第一件事是什么？

打开企业邮箱、登录钉钉或飞书、启动 Notion 做笔记、查看 Jira 任务、再打开 Google Drive 找资料……如果每个服务都要单独输入账号和密码，一天下来至少要输十遍密码。

然而现实中并不是这样。用 Google 账号登录一次，Gmail、YouTube、Google Drive 就全部自动打通了。这就是 SSO（Single Sign-On，单点登录）。

"这不就是浏览器记住密码吗？"——您可能会这么想，但 SSO 和浏览器自动填充密码是完全不同的技术。接下来我们就来深入了解。

SSO 到底是什么？

SSO（Single Sign-On，单点登录）是一种只需完成一次身份认证，即可访问多个独立服务的统一认证体系。

用一个生活中的比喻来解释：

想象一下游乐园的通票手环。在入口处戴上手环后，园内所有游乐项目都可以随意体验，不需要逐个购票。SSO 就像这个通票手环。

手环（认证令牌） = 登录一次后获得的数字凭证

游乐园入口（身份提供者，IdP） = 验证身份并发放手环的地方

游乐项目（服务提供者，SP） = 只需查看手环就允许使用的各个服务

SSO vs 密码保存 vs 一个密码到处用

这三种方式容易混淆，我们来对比一下：

方式

工作原理

安全级别

管理便利性

一个密码到处用

所有服务使用同一个密码

极其危险 — 一处泄露全部暴露

省事但风险极高

密码管理器（1Password 等）

每个服务设置不同密码，由工具统一记忆

中等 — 依赖主密码安全性

适合个人场景

SSO

认证服务器一次验证后签发令牌

高 — 集中管控，可结合 MFA

企业环境最优选

密码管理器是"帮你记住多个密码"的工具，而 SSO 是从系统架构层面就只需要一个密码。两者在本质上完全不同。

SSO 是怎么运作的？

在深入技术细节之前，我们先跟着一次真实的登录流程走一遍。

典型的 SSO 登录流程

员工访问 Slack → Slack 发现"这个人是谁？"，于是向公司的认证服务器（IdP）发起询问

认证服务器弹出登录页面 → 员工用公司账号登录

认证服务器签发令牌，确认"此人身份属实" → 令牌传递给 Slack

Slack 验证令牌后放行访问

关键在第 3 步。此时员工再打开 Notion，由于在认证服务器上已处于登录状态，无需再次输入密码就能直接获取令牌。这就是"Single Sign-On"的核心 — 登录一次，处处通行。

SSO 的核心组件

IdP（身份提供者，Identity Provider）：负责验证用户身份并签发令牌的中央服务器。代表性产品有 Okta、Azure AD、Google Workspace。

SP（服务提供者，Service Provider）：接收 IdP 签发的令牌并授权用户访问的各个应用。如 Slack、Notion、Jira、Salesforce 等。

令牌/断言（Token/Assertion）：IdP 传递给 SP 的数字凭证，相当于"此用户已通过认证，拥有以下权限"。

SSO 三大协议：SAML、OAuth、OIDC

实现 SSO 有多种技术标准（协议），实际工作中最重要的有三个。

几分钟搞定投资人路演资料创业团队用AiDocX制作IR资料、追踪查看分析、加速融资进程 — 免费开始。创建路演资料 →

SAML 2.0 — 企业 SSO 的开山鼻祖

SAML（Security Assertion Markup Language） 诞生于 2005 年，是历史最悠久的 SSO 标准。

特点：基于 XML，专为企业环境设计

适用场景：大型企业内部系统对接、B2B SaaS 集成

局限：不适合移动端应用，配置较为复杂

打个比方，SAML 就像中国企业早年使用的 U 盾/CA 数字证书。虽然笨重、设置麻烦，但在企业级应用中拥有最广泛的使用率和信任度。

OAuth 2.0 — "授权访问"协议

OAuth 严格来说并非 SSO 协议，而是一种权限委托协议。

"是否允许这个应用访问我的 Google Drive？"——OAuth 处理的就是这类问题。当您点击"通过 Google 登录"按钮时，弹出的"此应用请求访问您的邮箱和个人资料"提示框，正是 OAuth 在工作。

特点：基于 JSON，轻量灵活

适用场景：社交账号登录、移动应用、API 对接

局限：本质是授权（Authorization）而非认证（Authentication）— 不告诉您"用户是谁"

OpenID Connect（OIDC）— 现代 SSO 的事实标准

OIDC 是在 OAuth 2.0 之上增加了身份认证层的协议。如果说 OAuth 只处理"授权访问"，那么 OIDC 还能告诉您"这个用户到底是谁"。

特点：OAuth 2.0 + 用户身份信息（ID Token）

适用场景：当下绝大多数 SaaS 服务，同时支持移动端和 Web 端

优势：比 SAML 轻量，比 OAuth 安全

目前新建的服务大多采用 OIDC。Google、Microsoft、Apple 的"使用 XX 登录"功能全部基于 OIDC。

协议选择指南

场景

推荐协议

理由

大型企业内部系统对接

SAML 2.0

兼容遗留系统，满足企业安全合规要求

SaaS 服务新建开发

OIDC

现代化设计，移动端友好

仅需社交账号登录

OAuth 2.0

实现最简单

同时服务企业客户和个人用户

OIDC + SAML

以 OIDC 为主，为企业客户额外支持 SAML

企业部署 SSO 的五大理由

1. 从根源上解决密码问题

据统计，一名普通员工平均使用约 27 个办公类服务。让每个人为 27 个服务设置完全不同的密码，几乎不可能。最终结果往往是多个服务共用一个密码，或者设置"公司名2024!"之类容易被猜到的弱密码。

SSO 从根本上解决了这个问题。密码只存在于 IdP 一处，再为这唯一的密码叠加 MFA（多因素认证），安全等级将大幅跃升。

2. 离职员工账号即时封禁

员工离职时最大的安全隐患是什么？是散落在几十个服务中的账号需要逐一停用。只要漏掉一个，离职人员就可能继续访问公司数据。

在 SSO 环境下，只需在 IdP 中停用一个账号，所有关联服务的访问权限即刻失效。这也被称为"单点注销（Single Sign-Off）"。

3. 提升员工工作效率

Okta 的调研显示，员工每天平均输入 9.3 次密码。因忘记密码而提交的重置请求占 IT 服务台工单的 20%~50%。部署 SSO 后，这些数字几乎降为零。

4. 助力合规审计

无论是等保 2.0、ISO 27001，还是 SOC 2 等安全认证，"访问控制"和"审计日志"都是必检项。SSO 让所有服务的访问记录集中到 IdP，谁在什么时间访问了哪个服务，一目了然。

5. 降低 IT 管理成本

新员工入职时无需在每个服务中逐一创建账号，只需在 IdP 中注册一次即可自动获得所需服务的访问权限。这就是自动配置（Auto Provisioning）。结合 SCIM 协议，入职、离职、部门调动时权限都能自动同步调整。

部署 SSO 前必须了解的注意事项

SSO 并非只有优点。部署前务必考虑以下几点：

单点故障（Single Point of Failure）

如果 IdP 宕机了怎么办？所有服务都将无法登录。这是 SSO 最大的风险。因此企业级 IdP 通常承诺 99.99% 的可用性，并默认采用双机热备架构。

应对方案：单独保留紧急管理员账号，并制定 IdP 故障时的应急访问预案。

初始建设成本与复杂性

部署 SSO 不是"装个插件"那么简单。需要逐一确认在用服务是否支持 SSO，然后与 IdP 逐个配置对接。如果存在老旧系统，可能根本无法集成。

务实建议：不要试图一次性全部切换，优先从核心服务（邮箱、协作工具）开始分阶段推进。

IdP 供应商锁定（Vendor Lock-in）

所有认证都集中在单一 IdP 上，更换 IdP 将是一项浩大的工程。初始选型至关重要。

应对方案：选择支持 SAML/OIDC 等标准协议的 IdP，后续迁移会相对顺畅。尽量避免使用私有协议的 IdP。

SSO 旁路账号管理

即使部署了 SSO，部分服务中仍可能残留不经过 SSO 验证的本地管理员账号。这些"后门"需要定期审计排查。

文档管理平台与 SSO

在处理合同、IR Deck、投资资料等敏感文档的平台中，SSO 的重要性尤为突出。

为什么？

合同中包含金额、条款、商业机密等关键信息

IR Deck 中涉及未公开的财务数据

多个外部相关方（投资人、法律顾问、合作伙伴）需要访问文档

没有 SSO 的情况下，需要为每位用户单独创建账号，项目结束后还要逐一删除。而在 SSO 环境中，只需在 IdP 端调整访问权限即可。

AiDocX 等文档管理平台为企业客户提供基于 SAML/OIDC 的 SSO 支持，能够与企业现有的身份认证体系无缝对接。员工无需单独注册，直接用公司账号即可使用；IT 管理员则可在统一后台集中管控文档访问权限。

SSO 部署实施清单

如果您正在考虑部署 SSO，以下清单可供逐项检查：

第一阶段：现状摸底

梳理当前使用的所有 SaaS 服务清单

确认每个服务是否支持 SSO（SAML/OIDC）

针对不支持 SSO 的服务制定替代方案

统计当前密码相关的安全事件及 IT 服务台工单情况

第二阶段：选择 IdP

确认与现有服务的兼容性

是否支持 MFA（多因素认证）

是否支持 SCIM（自动配置）

对比定价模型（按用户数计费 vs 固定费用）

确认 SLA（服务可用性保障级别）

第三阶段：分步实施

确定试点团队（如 IT 部门）

优先对接核心服务（邮箱、协作工具）

制定应急访问预案

组织全员培训与通知

制定原有本地账号清退计划

主流 IdP 服务对比

IdP

特点

价格区间

适用企业

Okta

SaaS 集成数量最多，市场份额第一

$6~15/人/月

中大型企业

Azure AD（Entra ID）

与 Microsoft 365 深度整合

含于 M365 或 $6 起/人/月

微软生态企业

Google Workspace

Google 服务自动实现 SSO

含于 Workspace 订阅

Google 生态企业

OneLogin

界面直观，配置快速

$4~8/人/月

初创及中小企业

JumpCloud

设备管理一体化

$7~15/人/月

远程办公企业

总结：SSO 不是可选项，而是基础设施

SSO 不仅仅是"让登录变得方便的技术"，它是企业安全、生产力和 IT 管理效率的底层基础设施。

总结建议：

10 人以下初创团队：从 Google Workspace 或 Microsoft 365 自带的基础 SSO 起步即可，无需额外成本就能享受基本的单点登录体验。

10~100 人成长期企业：建议引入 Okta、OneLogin 等专业 IdP。随着使用的服务越来越多，SSO 的价值将愈发明显。

100 人以上规模企业：需要构建 SSO + SCIM（自动配置）+ MFA 相结合的综合 IAM（身份与访问管理）策略。

无论企业规模大小，**在引入新的 SaaS 服务时，请务必确认其是否支持 SSO。**不支持 SSO 的服务，日后很可能成为安全盲区。

如果您需要处理合同、IR Deck 等敏感文档，SSO 就更加不可或缺。AiDocX 支持企业级 SSO，与企业内部认证体系深度对接，让文档安全与访问管控在一个平台上集中完成。

Related Resources

Startup Fundraising Documents — Build investor-ready pitch decks and fundraising docs

Notion Alternative — See how AiDocX compares to Notion for documents