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