使用 AAD 应用程序密钥和服务主体密码之间的身份验证区别

Question

要在 Azure 中运行应用程序，我需要在 Azure AD 中创建一个应用程序和一个相应的服务主体。然后我的应用程序针对这个 App/Principal 对进行身份验证。要进行身份验证，我可以在应用注册中创建一个应用程序密钥，或者我可以在服务主体中创建一个密码（以及其他选项）。从实际角度看有什么区别？

例如，无论 $key 是应用程序的密钥还是服务主体的密码，这段代码的运行方式完全相同（从外部）：

    $key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force
    $cred = New-Object System.Management.Automation.PSCredential($appID, $key)
    Add-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal

什么时候应该对应用进行身份验证，什么时候应该使用服务主体？

Answer 1

首先，让我解释一下为什么它在 Azure AD 中同时具有应用程序和服务主体。以下是 Vittorio Bertocci 对使用 Azure AD for Web App 进行 Mordent Authentication 的解释。

Azure AD 定义了一个新实体，即应用程序，旨在 将应用程序描述为一个抽象实体：一个模板，如果你 将要。作为开发人员，您使用应用程序。在部署时 给定的 Application 对象可以作为蓝图来创建一个 ServicePrincipal 表示应用程序的具体实例 一个目录。就是那个 ServicePrincipal 用来定义什么 该应用程序实际上可以在该特定目标目录中执行，谁可以使用 它，它可以访问哪些资源，等等。

请耐心等待 再过一会儿，抽象的部分就差不多结束了。主要途径 Azure AD 从应用程序创建 ServicePrincipal 是 同意。以下是流程的简化描述：假设您 在目录 A 中创建一个 Application 对象，提供所有 到目前为止，我们在前面的章节中已经讨论过协议坐标。说 来自租户 B 的用户导航到应用程序的页面并触发 身份验证流程。 Azure AD 对来自 B 的用户进行身份验证 它的主目录 B。这样做时，它发现没有 B 中应用的 ServicePrincipal；因此，它会提示用户 他或她是否愿意同意该应用访问 目录 B（稍后你会看到它的容量）。如果用户授予 同意，Azure AD 使用 A 中的 Application 对象作为蓝图 在 B 中创建一个 ServicePrincipal。除此之外，B 还记录了当前用户同意使用此应用程序（稍后会详细说明）。完成后，用户会收到一个用于访问应用程序的令牌。

如果你想知道Azure AD App key和服务主体密码的区别，你最好知道Application和服务主体的关系。我将在此处复制并粘贴来自this page of the documentation的一些摘录

1. 当您在 Azure 门户中注册 Azure AD 应用程序时，会在您的 Azure AD 租户中创建两个对象：一个应用程序对象和一个服务主体对象。

2. 将应用程序对象视为应用程序的全局表示以供所有租户使用，将服务主体视为本地表示以供特定租户使用。应用程序对象用作模板派生了哪些通用和默认属性以用于创建相应的服务主体对象。

3. 因此，应用程序对象与软件应用程序具有 1:1 关系，与其对应的服务主体对象具有 1:many 关系。必须在使用该应用程序的每个租户中创建服务主体，从而启用它建立用于登录和/或访问由租户保护的资源的身份。

示例图

总结

现在，我们可以知道 Azure AD 应用程序密钥和服务原理密码之间的区别了。它们属于不同的对象。要与服务主体关联的密码。这仅适用于应用程序租户登录 azure。但是，您可以提供带有应用程序 ID 的 App 键值，以使用所有租户作为应用程序登录。

要查看有关 Azure Active Directory 中的应用程序和服务主体对象的更多详细信息，您可以参考this document。