通过

在 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 管理中心中应用程序配置选项的屏幕截图。

将多租户应用加入到外部租户可以像运行一个应用并让用户登录该应用一样简单。 当租户允许用户同意（用户可以在没有管理员事先批准应用的情况下登录应用）时，加入某个应用只需要用户登录到该应用即可。 这一面向开发人员的标识研讨会（时间代码 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 365 应用合规性计划。 使用经验证的域表明你对自己的域具有控制权。 发布者验证表明 Microsoft 已验证组织的真实性。 在 Microsoft Entra ID 应用库中列出你的应用表明你的应用可通过 Microsoft Entra ID 轻松加入。 借助 Microsoft 365 合规性计划，你可以通过发布者证明、Microsoft 365 认证或 Azure 中的应用合规性自动化工具 (ACAT) 告知客户你的应用的安全性和合规性。 该计划展示了应用程序如何保护客户授权应用访问的资源。

后续步骤