在 Microsoft Entra ID 生态系统中建立应用程序

在 Microsoft Entra ID 上生成应用程序时,首先需要为应用程序建立标识。 应用需要使用 Microsoft Entra ID 中的标识才能请求令牌。 应用程序编程接口 (API) 需要使用 Microsoft Entra ID 中的标识才能为应用颁发令牌来访问资源。

本文将介绍如何通过 Microsoft Entra 管理中心或 Microsoft Graph API 在 Microsoft Entra ID 租户中注册应用。 这是关于独立软件开发人员 (ISV) 如何为 Microsoft Entra ID 生成和优化其应用程序的系列文章中的第二篇文章。 在此系列中,可以了解有关以下主题的详细信息:

注册应用程序

开发人员可以将应用程序注册为多租户应用和单租户应用。 对于 ISV,我们建议注册为多租户应用。 多租户应用具有 ISV 在其租户中完全控制并注册的单个应用注册。 了解如何创建 Microsoft Entra ID 租户以注册应用。

若要向任何运行 Microsoft Entra ID 的客户提供解决方案,并支持无缝加入客户的 Microsoft Entra ID 租户中,请依次转到“Microsoft Entra 管理中心”、“应用注册”、“注册应用程序”。 在此新应用注册中,请选择“支持的帐户类型”、“任何组织目录中的帐户(任何 Microsoft Entra ID 租户 - 多租户)”或“任何组织目录中的帐户(任何 Microsoft Entra ID 租户 - 多租户)和个人 Microsoft 帐户(例如 Skype、Xbox)”

Microsoft Entra 管理中心中应用程序配置选项的屏幕截图。

将多租户应用加入到外部租户可以像运行一个应用并让用户登录该应用一样简单。 当租户允许用户同意(用户可以在没有管理员事先批准应用的情况下登录应用)时,加入某个应用只需要用户登录到该应用即可。 这一面向开发人员的标识研讨会(时间代码 1:05:20 到 1:08:00)将显示用户在登录应用时加入租户中的应用。

在 Microsoft Entra ID 租户中注册应用时,租户会收到应用程序 ID(应用 ID),该 ID 也称为应用的客户端 ID。 它就像其中的用户的 userid,将会唯一标识一个应用。 应用 ID 在整个 Microsoft Entra ID 云中是全局唯一的且不可变。 应用与 Microsoft Entra ID 之间的所有交互都包含应用 ID。

除了应用 ID,应用注册还包含应用开发人员知道或需要知道的应用相关信息。 例如,应用开发人员需要知道应用 ID 才能与 Microsoft Entra ID 交互。 开发人员知道他们正在生成的应用程序类型(Web 应用、本机应用、单页应用、移动应用或桌面应用)。 应用程序类型具有必需的属性。

例如,重定向统一资源标识符 (URI) 便是一个必需的应用程序属性。 该属性将告知 Microsoft Entra ID 要在身份验证或授权后发送给用户的 Web 地址或本机应用地址。 开发人员将根据应用类型和应用运行位置获知应用程序的重定向 URI。

应用的清单(可通过 Microsoft Entra 管理中心或 Microsoft Graph API 进行访问)会存储许多应用程序属性。 请参考了解 Microsoft Entra 应用部件清单,了解应用属性及其允许的值。

请参考用于 Microsoft 标识平台身份验证和授权的代码示例,了解有关要开发的应用的建议设置。 查找与要生成的应用类似的应用程序示例并阅读其文档。 示例将按应用类型详细说明所需的应用注册设置。 例如,如果要在 Node.js 中生成 API,可以查找一些示例来引导你了解这些注册说明

应用注册会传达开发人员所知道的内容。 在用户可以向多租户应用进行身份验证的每个租户中,租户管理员将配置应用程序在其租户中的运行方式。 例如,租户管理员可以设置条件访问策略来将应用限制到特定的网络位置。 此外,还可以通过条件访问策略要求用户通过多方式认证 (MFA) 来访问应用,或通过应用设置来允许特定用户或组使用应用。

若要启用此类限制,租户管理员需掌握对其租户中的应用的控制点。 Microsoft Entra ID 会在用户对应用进行身份验证的每个租户中自动创建一个企业应用程序。 在 Microsoft Entra 管理中心中,它们称为“企业应用程序”,但对象是服务主体。 详细了解 Microsoft Entra ID 中的应用和服务主体

在用户对应用进行身份验证后,Microsoft Entra ID 会在用户进行身份验证的租户中创建一个服务主体。 租户管理员可以在 Microsoft Graph 中(或在“Microsoft Entra 管理中心”的“企业应用程序”中)使用该服务主体对象来配置应用在租户中的工作方式

服务主体不是应用注册的副本,即使它们具有许多相同的属性。 相反,服务主体会链接到其应用注册。 你可以在链接的企业应用程序中查看对应用注册的更新。 对于多租户应用,客户无权访问 ISV 租户中的应用注册。 但是,应用程序可以使用 Microsoft Graph 访问其服务主体,即使该服务主体位于其他租户中也是如此。 因此,应用可以访问有关企业应用程序的属性(例如,它是需要将用户分配给某个应用,还是将用户分配给该应用中的某个角色)。

虽然我们建议 ISV 在应用注册中选择多租户应用,但单租户应用也是一个用于注册应用的选择。 你可以要求客户在其租户中注册你的应用,而不是在 ISV 完全控制注册的 ISV 租户中进行单应用注册。 客户在完成注册后,会使用其应用注册的详细信息配置应用实例。 我们建议将这种单租户应用方法主要用于为特定企业开发的业务线应用程序。

由于要求客户注册和配置你的应用程序所产生的开销,我们不建议 ISV 选择单租户应用。 但是,在某些情况下,你的应用不允许选择多租户应用。

如果应用使用安全断言标记语言 2.0 (SAML),而不是 OpenID Connect (OIDC) 或 OAuth 2.0,则将遵循单租户应用注册模型。 对于 SAML 应用,创建服务主体和应用注册的顺序与 OIDC 或 OAuth 2.0 应用相反,至少对于将 SAML 应用添加到租户的管理员而言是如此。 管理员将首先创建企业应用,而不是注册应用并让 Microsoft Entra ID 自动创建服务主体。 Microsoft Entra ID 会自动创建应用注册。 发布应用程序部分中介绍的 Microsoft Entra ID 应用库为管理员简化了 SAML 应用创建过程。

重定向统一资源标识符 (URI) 的限制可能会阻止 ISV 创建多租户应用。 应用最多可以有 256 个重定向 URI,且不带通配符。 如果应用程序需要每个客户都有一个唯一的重定向 URI,并且有超过 256 个客户需要唯一实例,则可能无法创建多租户应用。 出于安全原因,无法在 Microsoft Entra ID 重定向 URI 中使用通配符 (*)。 一个选项是采用一个针对中心服务的重定向 URI(如果可以提供中心服务)。 中心重定向 URI 将验证令牌,然后将用户重定向到其特定于客户的终结点。

发布应用程序

当用户初次对你的应用进行身份验证或授权应用访问该用户的资源时,他们将决定是否信任你的应用。 管理员可以为租户中的所有用户做出类似的决策。 管理员可以决定用户是否可登录某个应用,以及应用是否可访问特定资源。

以下应用发布方法可帮助 ISV 将其应用呈现为值得用户和管理员信任的应用。

  • 经过验证的域发布应用。 发布者域会通知用户和管理员哪些位置将接收其信息。 从经过验证的发布者域进行发布表明应用的已注册租户对列为应用发布者的域具有控制权。
  • 使用发布者验证发布应用。 拥有经过验证的发布者域是实现发布者验证的先决条件,后者不再是仅仅表明应用发布者对域具有控制权。 发布者验证表明 Microsoft 已验证域和租户背后的实体是真实的。 非管理员用户通常不会信任未经验证的发布者提供的多租户应用。 管理员可以配置租户,使并非来自已验证发布者的应用始终需要征求管理员同意。 发布者验证主要适用于在 OAuth 2.0 和 OIDC 上生成多租户应用的 ISV。 经验证的发布者是 Microsoft 云合作伙伴计划的成员。 发布者验证不会影响单租户应用,例如使用 SAML 的应用或业务线应用。
  • Microsoft Entra ID 应用库中发布应用。 你可以请求 Microsoft 在 Microsoft Entra ID 应用库中列出你的使用 SAML 2.0 的应用,以及那些使用 OAuth 2.0 和 OIDC 的应用。 管理员可以通过依次导航到“Microsoft Entra 管理中心”、“企业应用程序”、“新应用程序”来查找 Microsoft Entra ID 应用库中的预集成应用。 在 Microsoft Entra ID 应用库中发布应用可以简化并最大限度地减少应用的配置。 Microsoft 将测试应用程序并提供兼容性验证,这对于使用 SAML 2.0 且需要在使用前进行配置的应用尤其有用。 你可以使用应用的跨域标识管理系统 (SCIM) 2.0 实现来配置应用库应用。有关如何进行预配,请参阅自动预配部分。 若要开始,请提交请求以发布应用程序。 你可以将 SCIM 与应用库中的单个应用程序配合使用,来实现单一登录和用户预配。
  • 参加 Microsoft 365 应用合规性计划 使用经验证的域表明你对自己的域具有控制权。 发布者验证表明 Microsoft 已验证组织的真实性。 在 Microsoft Entra ID 应用库中列出你的应用表明你的应用可通过 Microsoft Entra ID 轻松加入。 借助 Microsoft 365 合规性计划,你可以通过发布者证明Microsoft 365 认证或 Azure 中的应用合规性自动化工具 (ACAT) 告知客户你的应用的安全性和合规性。 该计划展示了应用程序如何保护客户授权应用访问的资源。

自动预配

Microsoft Entra ID 中的应用预配可以自动将用户标识、组对象和角色预配到用户需要访问的云应用程序。 除了创建用户和组对象之外,自动预配还包括随状态或角色变化而维护和移除用户标识。 Microsoft Entra 预配服务将通过调用应用程序提供的 SCIM 对象管理 API 终结点来自动将用户和组预配到应用程序。

对于 ISV,Microsoft Entra ID 中的应用预配的优点包括以下方面。

  • 可以使用 Microsoft Graph 预配到应用程序,而通过构建 SCIM 终结点,可以预配为使用支持 SCIM 的标识提供者 (IdP)。 大多数 IdP 都支持 SCIM 预配协议。
  • 预配是一种同步操作,数据会在此期间在 Microsoft Entra ID 与应用程序之间进行同步。 若要实现基于 Microsoft Graph 的同步解决方案,应用需要能够访问租户中所有用户和组的所有属性。 某些 Microsoft Entra ID 客户将不愿意允许如此广泛的访问。 使用 SCIM,管理员可以选择 Microsoft Entra ID 同步到应用程序的属性。 许多管理员更希望能够拥有这种精细的控制,而这种控制仅适用于 SCIM 实现。
  • 生成自己的 Microsoft Graph 同步服务来进行预配意味着你必须管理该服务,并实现拉取模型来监视 Microsoft Entra ID 的更改。 实现 SCIM 终结点时,Microsoft Entra ID 会管理预配服务管理并将更改推送到应用。

使用 SCIM、Microsoft Graph 和 Microsoft Entra ID 预配用户并扩充应用中的数据提供了有关何时使用 SCIM 和何时使用 Microsoft Graph 的指导。 请根据 Microsoft 文档来使用 Microsoft Entra ID 规划生成验证 SCIM 终结点,并解决 SCIM 合规性方面的已知问题

除了将数据同步到应用程序之外,Microsoft Entra ID 还提供基于云的人力资源 (HR) 应用程序预配。 HR 驱动的预配即基于人力资源解决方案创建数字标识的过程。 HR 系统成为了这些新创建的数字标识的授权起始点,并且通常是许多预配过程的起点。 本地 HR 解决方案可以使用 Microsoft Identity Manager 将用户预配到本地 Active Directory。 然后,它们可以使用 Microsoft Entra Connect 同步到 Microsoft Entra ID,或直接同步到 Microsoft Entra ID。

借助 API 驱动的入站预配,基于云的 HR ISV 可以提供本机同步体验,以便 HR 系统中的更改自动流入 Microsoft Entra ID 和已连接的本地 Active Directory 域。 例如,HR 应用或学生信息系统应用可以在事务完成或在一天结束批量更新时立即将数据发送到 Microsoft Entra ID。 若要开始了解 API 驱动的入站预配概念,请研究 Microsoft Graph 中的 bulkUpload 功能,并进一步熟悉 API 驱动的预配方面的概念、场景和限制

后续步骤