您可能已经在处理这种情况了。员工登录 Microsoft 365，然后是预订工具，接着是 HR，然后是业务线应用，最后是企业 WiFi，通常每一种都使用不同的方式。一家酒店集团在总部有一套系统，在酒店现场又有另一套系统。一家医院拥有临床应用、共享工作站和分段的无线访问。一家零售运营商的员工需要在门店、平板电脑、POS 和后台仪表板之间移动。
这种混合很快就会产生摩擦。用户忘记密码，IT 团队重置账户，而共享的 WiFi 凭据在本该删除后很久仍然残留。其结果不仅是令人烦恼，还会削弱对谁可以从哪台设备访问什么内容以及访问多长时间的控制。
这就是单点登录（即 SSO）发挥作用的地方。如果您正在寻找什么是单点登录，简短的答案很简单：它允许用户进行一次身份验证，然后即可访问多个经批准的系统，而无需反复输入凭据。更具实用价值的答案在于运营层面。SSO 为 IT 部门提供了一个统一的身份层来访问应用，并且在合适的设计下，它还可以支持人员和设备加入安全网络的方式。
终结密码混乱
大多数企业环境并非刻意变得混乱，而是随着业务发展而演变成那样的。一个云应用程序变成了五个。一个办公室变成了多个站点。一个用于 IT 的无线网络变成了针对员工、访客、承包商和设备的独立 SSID。
这就是密码泛滥的开始。一名员工在开展任何实际工作之前，可能需要访问电子邮件、人力资源系统、排班系统、文件访问权限、内部仪表板以及网络访问权限。IBM 将 SSO 描述为一种方案，即用户使用一组凭据登录一次，即可在同一会话中访问多个应用程序，这得益于服务提供商与身份提供商之间的信任关系。IBM 对 单点登录 的概述，与随着云采用和远程办公加速英国组织所产生的需求高度契合。
密码蔓延对业务运营的影响
当每个应用程序都要求独立登录时，用户就会开始寻找捷径。他们会重复使用密码。他们会在浏览器中保存密码。他们会向同事询问“员工 WiFi 密码”，因为这比等待 IT 响应要快。
对于企业 IT 经理而言，控制权是首要考虑的问题。独立的登录会创建独立的访问孤岛，当人员变动角色、离职或在多个地点工作时，这些孤岛将更难管理。
密码混乱很少是一次性的大失败。它通常是由一百个没人能够一致管理的小型访问决策造成的。
为什么 SSO 能够改变现状
SSO 减少了用户需要管理的密码数量，从而改善了登录体验，并在与中央策略和 MFA 结合使用时支持更强的安全性。它也符合分布式组织的实际情况，在这些组织中，员工需要在电子邮件、HR、预订工具、POS、内部应用和现场服务中使用同一个登录账号。
同样的逻辑现在也在塑造网络访问。如果您已经在转向以身份为核心的应用程序访问，那么将免密 WiFi 视为同一设计方案的一部分，而不是将其作为一个独立的问题来对待，是顺理成章的。
理解核心 SSO 概念
SSO 将身份验证从每个单独的应用程序转移到单一的可信身份系统中。用户登录一次，该身份得到验证，已连接的服务就会接受该结果，而不会再次要求输入密码。
这听起来很简单，但其价值在于架构。您正在改变信任关系的存在位置。
每个 SSO 流程中的三个要素
每个 SSO 设计都有三个参与者，每个参与者承担不同的工作：
- 用户希望访问应用程序、服务或网络资源。
- 身份提供商（IdP）负责验证身份并应用登录策略。英国组织中的常见示例包括 Microsoft Entra ID 和 Okta。
- 服务提供商（SP）是用户尝试访问的系统，例如 Salesforce、预订平台、企业内网或其他业务系统。
经常引起混淆的一点是信任。应用程序本身不需要收集和检查密码。它依赖于IdP正确完成该工作，然后接受其结果。
信任关系真正意味着什么
Auth0 用企业术语清晰地解释了 SSO：IdP 对用户进行一次身份验证，然后颁发一个会话伪件或令牌，受信任的服务提供商会对其进行验证以供后续访问。在实际应用中，用户会被重定向到 IdP，在其中完成身份验证，然后返回到每个应用程序，而无需重复提示输入凭据。Auth0 编写的关于 单点登录如何工作 的指南，在跨 SaaS 和内部系统使用 Microsoft Entra ID 的英国环境中特别具有参考价值。
一种更通俗的理解方式如下：
- 用户打开应用程序。
- 应用程序检查可信的 IdP 是否已对该用户进行身份验证。
- 如果不存在活动会话，用户将登录到 IdP。
- IdP 确认身份并返回应用程序可以验证的凭证。
- 其他连接的系统可以在会话期间接受该相同凭证。
实用规则：SSO 并未将每个系统转变为一个平台。它为多个系统提供了一个验证身份的统一场所。
为什么这在 Web 应用之外也同样重要
这也是 SSO 不仅仅是一项 SaaS 便利服务的地方。一旦身份实现集中化，相同的模型就可以用于浏览器会话以外的更多场景。它还可以决定您如何控制对内部服务的访问，并且在设计合理的情况下，决定用户如何加入企业无线网络。
这对于 IT 运维至关重要。财务应用程序、VPN 会话以及员工 WiFi 连接可能是不同的服务，但它们都始于同一个问题：该用户是谁，是否应允许其进入？当 Microsoft Entra ID 或 Okta 一致地回答了该问题时，跨应用程序和网络入口点的访问策略就会变得更容易管理。
对于仍在使用共享密码运行员工 WiFi 的团队来说，这是一个重大转变。您无需使用人尽皆知的密码对设备进行身份验证，而是根据可信的身份来源对个人或受管设备进行身份验证。这为您提供了更严格的控制、更清晰的审计轨迹，以及在角色变更或雇佣结束时更干净的取消访问权限的方法。
SSO 的工作原理 - 核心协议
用户体验看起来很简单。在底层，SSO 依赖于标准协议，这些协议允许应用程序信任在其他地方做出的身份决策。
对于企业 IT 经理来说，实际问题不仅仅是“什么是 SSO？”，而是“一个系统如何在不要求用户重新登录的情况下接受另一个系统的证明？”答案取决于一套在应用程序、身份提供者以及有时是设备本身之间传输身份数据的协议。
这不仅关乎浏览器登录。用于打开 SaaS 应用的相同信任模型，在将这些访问决策与 Microsoft Entra ID、Okta 或其他中央身份源绑定时，也会影响用户连接到 VPN、有线网络和企业 WiFi 的方式。
通俗易懂的 SAML 介绍
SAML 2.0 在企业 SSO 中仍然很常见，特别是对于成熟的 SaaS 平台和业务线系统。
SAML 的工作原理是在应用程序和身份提供者之间传递受信任的身份声明。用户尝试打开一个应用程序。应用程序将他们重定向到 IdP。IdP 对用户进行身份验证并返回一个经过数字签名的断言。应用程序验证该签名，接受身份声明，并创建一个会话。
该流程适合浏览器承担大部分工作且应用程序期望进行正式、基于标准的交换的环境。
SAML 通常非常适合：
- 企业 SaaS - 例如人力资源、财务或传统业务应用
- 基于浏览器的流转工作 - 用户通过网页会话访问系统
- 中央策略强制执行 - 适用于 IT 希望在单一位置管理身份验证的情况
通俗易懂的 OAuth 和 OIDC
OAuth 2.0 最初是作为一种在不共享完整凭据的情况下授予对资源有限访问权限的方法。就其本身而言，它关乎授权。
OpenID Connect（即 OIDC）在 OAuth 2.0 之上添加了身份层。这为现代应用程序提供了一种标准方式来确认用户是谁，同时仍然使用基于令牌的访问模式。如果说 SAML 通常适用于较旧的以浏览器为中心的 SaaS，那么 OIDC 通常适用于较新的 Web 应用、移动应用和 API 驱动的服务。
在实践中，OIDC 往往让现代开发团队感觉更轻量，因为令牌在前端应用、后端服务和移动客户端之间运行良好。对于 IT 部门而言，这意味着当应用程序不是传统的浏览器会话时，可以减少棘手的变通方案。
OIDC 通常适合：
- 现代云应用程序
- 移动和单页应用程序
- 令牌已成为设计一部分的重度 API 环境
关于 Kerberos 的简要说明
在 SSO 讨论中，您可能还会听到 Kerberos。Kerberos 与传统的 Active Directory 环境和本地 Windows 身份验证紧密相关。它在企业内部资产中仍然具有相关性，尤其是在域加入设备和传统应用依然普遍的环境中。
尽管如此，许多当前的 SSO 项目都专注于跨云和混合服务的联合身份。在这些情况下，SAML 和 OIDC 通常会获得更多关注，因为它们能更自然地连接到 SaaS 平台和外部可访问的服务。
SAML 与 OIDC 一览
| 功能 | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| 主要角色 | 企业级 Web 应用程序的身份验证 | 授权，并通过 OIDC 添加身份信息 |
| 常见使用场景 | 成熟的 SaaS 和基于浏览器的企业级应用程序 | 现代 Web 应用程序、移动应用程序、API |
| 格式 | 基于 XML 的断言 | 基于令牌（Token）的流 |
| 典型流程 | 重定向至 IdP，进行身份验证，返回签名的断言 | 重定向或令牌流，然后应用程序使用令牌进行身份识别和访问 |
| 最佳契合点 | 传统企业级 SSO 集成 | 较新的云原生和以应用程序为中心的架构 |
IT 经理最关心的要点
协议名称不如设计选择重要。您需要对四个运营问题有清晰的答案：
- 哪些应用支持 SAML 或 OIDC
- 哪个 IdP 将作为您的中央控制平面
- 如何强制执行会话超时、MFA 和条件访问
- 网络访问（包括员工 WiFi）是否也应针对该同一源验证身份
最后一点正是 SSO 对基础设施团队特别有用的地方。如果您的无线平台可以使用与您的 SaaS 资产相同的身份层，那么从登录页面到网络边缘，访问策略就会变得更加一致。这就是许多团队在评估 单点登录在访问控制和运营方面的优势 时，也开始考虑基于身份的 WiFi 身份验证，而不仅仅是 Web 应用登录的原因之一。
权衡收益与安全折衷
SSO 经常被作为一项方便用户的功宣传。这低估了它的价值。如果应用得当，它是一种访问控制模型，可以同时改善用户体验并收紧运营安全。
Okta 指出，SSO 的技术优势不仅在于便利性。它还减少了密码泛滥和重复登录事件，从而降低了服务台的工作负载并减少了用户摩擦。Okta 关于 单点登录安全性 的概述还强调了架构师关注的一个要点：如果 IdP 会话失效，连接的应用程序可以在下一次令牌检查时拒绝访问。
业务价值的体现之处
第一个好处是更简单的访问。用户只需登录一次，就能更快地开始工作，不再将身份验证视为日常障碍。
第二点是更强大的中央控制。IT部门可以从一个身份层应用多因素身份验证（MFA）、条件访问、会话策略和撤销，而无需在每个应用程序内部去调整设置。
第三个好处是更干净的入职、调动和离职处理。当身份集中管理时，入职和离职流程会变得更加一致。这就是探索 single sign-on benefits 的团队经常将 SSO 项目与更广泛的身份治理工作联系起来的原因之一。
您应该认真对待的权衡
存在一个切实的“万能钥匙”安全担忧。如果攻击者攻破了用户的主登录账号，其波及范围可能会更大，因为一个账户可能会提供对许多系统的访问权限。
此外还存在弹性风险。如果身份提供商不可用，对已连接服务的访问可能会中断。而且集成并不总是很顺畅。旧版应用、小众系统和本地网络服务并不总是能完美契合现代 SSO 模型。
正确的问题不在于 SSO 是否存在折衷，而在于您是宁愿集中管理这些折衷，还是继续管理几十个互不相连的折衷。
常见的缓解措施
采用分层防御方法：
- 通过 MFA、条件访问、设备信任和强大的管理员控制来重度保护 IdP。
- 规划弹性，避免 IdP 问题导致整个组织陷入停顿。
- 从高价值应用和明确的用户组开始，分阶段推出。
- 定期审查访问权限，确保过期的权限不会在不再需要后长期存在。
糟糕的 SSO 部署可能会使问题集中化。而强大的部署则能使控制集中化。
超越 Web 应用程序的 SSO：网络和 WiFi 访问
大多数文章仅止步于 SaaS。这很有用，但并不完整。在实际环境中，员工不仅需要应用程序访问权限。当他们到达现场、连接托管笔记本电脑、在分支机构打开平板电脑或在不同场所之间漫游时，他们都需要安全的网络访问。
这就是 SSO 讨论变得更有趣的地方。处理 Microsoft 365、人力资源系统或内部仪表板访问权限的同一个身份提供商，也可以成为无线认证策略的可信源。
Optimal IdM 在其关于 单点登录采用情况 的讨论中报告称，北美有 52% 的 IT 专业人员使用 SSO 进行身份管理。对于拥有多个场馆或物业的英国组织而言，这种成熟度至关重要，因为员工通常需要安全地访问共享系统，而无需重复登录。
应用程序 SSO 与网络身份相关，但并不相同
读者经常混淆的一个地方是，应用程序的 SSO 与基于身份的网络访问是相互关联的概念，但它们并不是同一种机制。
应用 SSO 通常意味着用户只需向 IdP 进行一次身份验证，即可获得连接应用所接受的令牌或会话。网络访问通常使用不同的控制方式，例如设备证书、无线身份验证方法、基于目录的策略以及合规性或信任检查。
将它们联系在一起的是身份源。如果 Microsoft Entra ID 或 Okta 已经知道用户是谁、他们属于哪个组以及他们的设备是否受管，您就可以使用该身份上下文来决定他们是否应该加入员工网络。
这在企业 WiFi 上是什么样子的
在成熟的设计中，员工根本不需要输入共享的 WiFi 密码。他们由组织管理的设备已经过注册、信任并与他们的身份相关联。当他们进入大楼时，设备会使用基于证书或同等企业身份验证的方式连接到相应的安全 SSID。
这在运营层面上带来了巨大的改变：
- 共享密码消失了，因此单个凭据泄露不会影响整个员工网络。
- 访问变得具有角色感知性，因为策略可以跟随身份组。
- 撤销变得更快，因为当目录访问发生变化时，网络访问也会随之改变。
- 漫游变得更容易，尤其是在用户期望在所有地方都获得相同体验的多站点资产中。
为什么这在酒店、零售和医疗保健行业至关重要
这些行业充满了边缘情况。这里有轮班员工、共享设备、代理员工、漫游团队，以及企业、半企业和访客访问需求的不断混合。
一家酒店集团可能希望一个员工身份能够管理跨物业的 PMS 访问、后台应用程序和安全的内部 WiFi。一家零售连锁店可能希望托管手持设备能够自动连接到门店 WiFi，同时保持访客流量隔离。一家医疗保健提供商可能希望在临床用户、访客和连接的设备之间进行更严格的隔离。
这也是 网络准入控制解决方案 引入讨论的地方。它们有助于将身份策略从应用层延伸到网络层。
Purple 的定位与作用
一个实用的选择是 Purple，它支持针对员工和多租户环境的基于身份的网络连接，包括与 Microsoft Entra ID、Google Workspace 和 Okta 的集成，以便在不依赖共享密码的情况下实现安全访问。当您希望应用程序身份和网络身份基于同一个单一事实来源工作时，这种方法非常有用。
SSO 在您所在行业中的实际应用案例
看待 SSO 价值最简单的方法是关注日常工作，而不是架构图。
酒店与酒旅行业
酒店运营经理在一家分店开始一天的工作，并在另一家分店结束。他们在这两个地点都需要访问排班系统、物业管理系统、共享文档以及内部 WiFi。
有了 SSO，该身份就会随之同行。他们只需登录一次，获得批准的系统就会识别该会话。如果组织还将网络访问与同一个身份源绑定，其托管设备就会自动加入员工 WiFi，而无需有人将最新密码发短信给值班经理。
零售
一位区域经理拿着平板电脑走进一家门店。他们需要立即使用销售仪表板、库存工具和内部沟通应用程序。
在零散的配置中，每个环节都可能意味着另一个登录提示、另一个过期的密码，或者又一次致电支持团队。在以身份为主导的模型中，平板电脑能够顺畅地进行身份验证，访问权限可反映用户的角色，而且门店员工无需共享本地凭据即可完成工作。
优秀的 SSO 不会让访问变得隐形。它能让合法的访问变得可预测。
医疗保健行业
临床医生开始轮班，需要快速、受控地访问核心系统。在一天之中，他们可能会在工作站、共享设备和受限网络段之间移动。
在这里，SSO 有助于减少对已批准应用的重复登录，而基于身份的网络控制则有助于确保正确的用户和设备连接到正确的无线环境。这种隔离至关重要。临床访问、访客访问和设备访问不应全部采用相同的管理方式。
多租户物业与园区
在学生公寓、商业中心和混合用途物业中，员工和居民通常共存于同一物理基础设施上，但绝不应该共享相同的访问模式。
员工可能需要楼宇系统、支持工具和内部管理应用程序。居民或租户需要可靠的连接，但不能访问运营平台。在这种情况下，身份设计最为重要。SSO 可以支持员工访问，而独立的网络身份策略则可以保持租户和访客流量的隔离。
SSO 部署与最佳实践
一个成功的 SSO 项目始于一个决定：选择将作为您控制平面的身份提供商。对于许多组织来说，这就是 Microsoft Entra ID 或 Okta，因为这些平台已经非常接近用户生命周期、MFA 和设备策略。
部署应该分阶段进行。从最重要的应用程序和最有可能受益的用户群开始。在扩大范围之前，清理重复账户，正确定义角色组，并测试会话行为。
最重要的控制措施
以下几项实践决定了这只是一个好看的演示，还是一个持久的部署：
- 在主要登录点要求进行多因素身份验证。 如果一次登录即可访问多种资源，那么该登录就需要更强大的保护。
- 围绕即时注销构建离职员工流程。 只有当账户变更快速生效时，中央身份管理才能发挥作用。
- 按角色审查访问权限。 如果无人检查谁仍拥有访问权限，SSO 可能会让过度授权更容易被忽视。
- 针对 IdP 中断制定预案。 了解如果您的身份服务不可用会发生什么，以及哪些系统需要后备处理。
了解何时不适用 SSO
这一点在许多通用的解释中都被忽略了。OneLogin 指出，在实际部署中，员工 SSO 与访客或设备访问之间的区别越来越大，并在其关于 单点登录如何工作 的解释中提出了一个对买家有用的问题：什么时候 SSO 是错误的工具，以及什么时候应该将身份应用于网络访问而不是应用程序登录？
这在 WiFi 设计中至关重要。员工通常应该使用与身份挂钩、由策略驱动的访问。而访客通常需要更轻量、更简单且独立的访问方式。试图强行让每种访问问题都通过员工 SSO 来解决，会在不需要的地方造成阻碍。
如果您正在将 SSO 作为更广泛的访问策略的一部分进行审查，请在同一次讨论中将应用程序、员工 WiFi、访客入网、共享设备和注销工作流纳入其中。这通常是获得最大运营收益的地方。
如果您正在重新审视应用程序、员工 WiFi、访客接入或多租户网络中的访问，Purple 值得一试。它提供基于身份的网络连接，可与 Microsoft Entra ID、Okta 和 Google Workspace 等平台协同工作，帮助团队用针对员工、访客和居民的受控访问来取代共享密码和繁琐的 Captive Portal。
