将身份验证委托给外部标识提供者。 这可以简化开发、最小化对用户管理的要求，并改善应用程序的用户体验。
上下文和问题
用户通常需要使用多个应用程序，这些应用程序由与用户有业务关系的不同组织提供和托管。 这些用户可能需要使用每个应用程序的特定（和不同）的凭据。 这可能：
导致用户体验不连贯。 当用户拥有许多不同的凭据时，他们常常会忘记登录凭据。
暴露安全漏洞。 当用户离开公司时，帐户必须立即取消设置。 在大型组织中尤为容易忽略这一点。
使用户管理复杂化。 管理员必须管理所有用户的凭据，并执行其他任务，例如提供密码提醒。
用户通常喜欢对所有这些应用程序使用同一凭据。
解决方案
实现可以使用联合身份的身份验证机制。 将用户身份验证与应用程序代码分离，并将身份验证委托给受信任的标识提供者。 这可以简化开发，并允许用户使用更广泛的标识提供者 (IdP) 进行身份验证，同时最小化管理开销。 它还允许明确地将身份验证与授权分离。
可信任的标识提供者包括公司目录、本地联合服务、由业务伙伴提供的其他安全令牌服务 (STS)，或可以对拥有 Microsoft、Google、Yahoo! 或 Facebook帐户的用户进行身份验证的社交标识提供者。
该图说明了当客户端应用程序需要访问要求身份验证的服务时的联合身份模式。 身份验证由与 STS 协同工作的 IdP 执行。 IdP 颁发安全令牌，该安全令牌提供已进行身份验证用户的信息。 该信息（又称为声明）包括用户的标识，并且还可包含其他信息（如角色成员资格和更具体的访问权限）。
此模型通常称为基于声明的访问控制。 应用程序和服务基于令牌中包含的声明授权访问功能。 需要身份验证的服务必须信任 IdP。 客户端应用程序联系执行身份验证的 IdP。 如果身份验证成功，IdP 将向 STS 返回包含标识用户的声明的令牌（请注意，IdP 和 STS 可以是同一服务）。 STS 可以基于预定义规则，在将其返回到客户端之前，转换和扩大令牌中的声明。 然后，客户端应用程序可以将此令牌传递到服务，作为其标识的证明。
在信任链中可能有额外的安全令牌服务。 例如，在下面描述的方案中，本地 STS 信任负责访问标识提供者以对用户进行身份验证的另一 STS。 这是在企业方案中的常见方法，其中包含本地 STS 和目录。
联合身份验证为跨不同域的信任标识的问题提供了一个基于标准的解决方案，并且可以支持单一登录。 此类型的身份验证在所有类型的应用程序（尤其是云托管应用程序）中变得越来越普遍，因为它支持单一登录，无需与标识提供者的直接网络连接。 用户不必为每个应用程序输入凭据。 这增加了安全性，因为它可避免访问多个不同应用程序所需的凭据创建，并且它还对除原始标识提供者外的所有标识提供者隐藏用户凭据。 应用程序仅可查看令牌中包含的已经过身份验证的标识信息。
联合身份还具有一大优点，即标识提供者负责管理标识和凭证。 应用程序或服务不需要提供标识管理功能。 此外，在公司方案中，如果公司目录信任标识提供者，则不需要知道用户。 这会免去在目录中管理用户标识的所有管理开销。
问题和注意事项
设计实现联合身份验证的应用程序时，请考虑以下事项：
身份验证可以是单点故障。 如果将应用程序部署到多个数据中心，请考虑将标识管理机制部署到同一数据中心，以维护应用程序的可靠性和可用性。
通过身份验证工具，可基于身份验证令牌中的角色声明配置访问控制。 这通常称为基于角色的访问控制 (RBAC)，并且它允许对功能和资源的访问进行较具体级别的控制。
与公司目录不同，使用社交标识提供者的基于声明的身份验证通常不提供经过身份验证的用户的信息（电子邮件地址和名称除外）。 某些社交标识提供者（如 Microsoft 帐户）仅提供唯一标识符。 应用程序通常需要维护注册用户的一些信息，并能够将此信息与令牌中的声明中包含的标识符相匹配。 这通常通过用户首次访问应用程序时的注册来完成，在每次身份验证之后，信息作为附加声明注入到令牌中。
如果为 STS 配置了多个标识提供者，则 STS 必须确定用户应重定向到哪个标识提供者（用于身份验证）。 这个过程称为主页领域发现。 STS 可以基于用户提供的电子邮件地址或用户名、用户正在访问的应用程序的子域、用户的 IP 地址范围或存储在用户浏览器 cookie 中的内容来自动执行此操作。 例如，如果用户在 Microsoft 域中输入电子邮件地址（例如 user@live.com），则 STS 会将用户重定向到 Microsoft 帐户登录页面。 在以后的访问中，STS 可以使用 cookie 来指示最后的登录使用的是 Microsoft 帐户。 如果自动发现无法确定主页领域，则 STS 会显示列出受信标识提供者的主页领域发现页，用户必须选择其中之一来使用。
何时使用此模式
此模式适用于以下方案：
企业中的单一登录。 在此方案中，需要对公司安全边界外的云托管的公司应用程序进行员工身份验证，而无需要求他们在每次访问应用程序时登录。 用户体验与使用本地应用程序时的用户体验相同，在登录到公司网络时进行身份验证，此后即可访问所有相关应用程序，无需再次登录。
与多个合作伙伴的联合身份。 在此方案中，需要对公司员工以及在公司目录中没有帐户的业务合作伙伴进行身份验证。 这在企业到企业应用程序、与第三方服务集成的应用程序，以及已合并或共享资源的具有不同 IT 系统的公司中很常见。
SaaS 应用程序中的联合身份。 在此方案中，独立软件供应商为多个客户端或租户提供即用型服务。 每个租户使用合适的标识提供者进行身份验证。 例如，公司用户将使用其公司凭据，而租户的使用者和客户将使用其社交标识凭据。
此模式在以下情况中可能不起作用：
应用程序的所有用户都可以由一个标识提供者进行身份验证，并且无需使用任何其他标识提供者进行身份验证。 这在使用公司目录（可在应用程序中访问）进行身份验证的业务应用程序中很典型，身份验证的方式是通过使用 VPN 或（在云托管方案中）通过本地目录与应用程序之间的虚拟网络连接。
最初使用不同的身份验证机制构建应用程序，可能使用了自定义用户存储，或不具备处理基于声明的技术使用的协商标准的能力。 将基于声明的身份验证和访问控制更新到现有应用程序可能很复杂，并且可能不具有成本效益。
工作负荷设计
架构师应评估如何在其工作负荷的设计中使用“联合标识模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性设计决策有助于工作负荷在发生故障后复原，并确保它在发生故障后恢复到正常运行状态。 | 卸载用户管理和身份验证将这些组件的可靠性转移到标识提供者，后者通常具有较高的 SLO。 此外，在工作负载灾难恢复期间，身份验证组件可能不需要作为工作负载恢复计划的一部分进行处理。 - RE:02 关键流 - RE:09 灾难恢复 |
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 通过外部化用户管理和身份验证，可以获取基于标识的威胁检测和预防的不断发展功能，而无需在工作负载中实现这些功能。 外部标识提供者使用新式可互操作身份验证协议。 - SE:02 安全开发生命周期 - SE:10 监控和威胁检测 |
| 性能效率通过在缩放、数据和代码方面进行优化， 帮助工作负载高效地满足需求。 | 卸载用户管理和身份验证时，可以将应用程序资源用于其他优先级。 - PE:03 选择服务 |
与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。
示例
某一组织在 Microsoft Azure 中托管有多租户软件即服务 (SaaS) 应用程序。 该应用程序包括一个网站，租户可以使用该网站为自己的用户管理应用程序。 当通过组织自己的 Active Directory 对用户进行身份验证时，应用程序允许租户通过使用由 Active Directory 联合身份验证服务 (AD FS) 生成的联合身份访问网站。
该图显示了租户如何使用自己的标识提供者（步骤 1，在本例中为 AD FS）进行身份验证。 对租户的身份验证成功后，AD FS 颁发一个令牌。 客户端浏览器将此令牌转发到 SaaS 应用程序的联合身份验证提供程序，该提供程序信任由租户的 AD FS 颁发的令牌，以便获取对 SaaS 联合身份验证提供程序有效的令牌（步骤 2）。 如果需要，在将新令牌返回到客户端浏览器之前，SaaS 联合身份验证提供程序将令牌中的声明转换为应用程序识别的声明（步骤 3）。 应用程序信任由 SaaS 联合身份验证提供程序颁发的令牌，并使用令牌中的声明来应用授权规则（步骤 4）。
租户无需记住单独的凭据来访问应用程序，并且租户公司的管理员可以在自己的 AD FS 中配置可以访问应用程序的用户列表。