首先,让我解释一下为什么它在 Azure AD 中同时具有应用程序和服务主体。这是 Vittorio Bertocci 对 Web App 的 Azure AD 进行 Mordent Authentication 的解释。
Azure AD 定义了一个新实体 Application,它旨在将应用程序描述为一个抽象实体:一个模板,如果你愿意的话。作为开发人员,您使用应用程序。在部署时,给定的 Application 对象可以用作蓝图来创建一个 ServicePrincipal,该 ServicePrincipal 表示目录中应用程序的具体实例。正是那个 ServicePrincipal 用于定义应用程序在该特定目标目录中实际可以做什么、谁可以使用它、它可以访问哪些资源等等。
再忍耐一下,抽象的部分就快结束了。Azure AD 从应用程序创建 ServicePrincipal 的主要方式是同意。下面是对流程的简化描述:假设您在目录 A 中创建了一个应用程序对象,提供了我们在前面章节中讨论过的所有协议坐标。假设租户 B 的用户导航到应用程序的页面并触发身份验证流程。Azure AD 根据其主目录 B 对来自 B 的用户进行身份验证。这样做时,它发现 B 中没有应用程序的 ServicePrincipal;因此,它会提示用户他或她是否要同意该应用程序访问目录 B(稍后您将看到以何种身份)。如果用户同意,Azure AD 使用 A 中的 Application 对象作为在 B 中创建 ServicePrincipal 的蓝图。除此之外,B 还记录当前用户同意使用此应用程序(稍后会详细说明)。完成后,用户会收到一个用于访问应用程序的令牌。
如果想知道 Azure AD App key 和 service principal Password 的区别,最好先了解 Application 和 service principal 的关系。我将在此处复制并粘贴此文档页面的一些摘录
-
在 Azure 门户中注册 Azure AD 应用程序时,会在 Azure AD 租户中创建两个对象:一个应用程序对象和一个服务主体对象。
-
将应用程序对象视为应用程序的全局表示以供所有租户使用,将服务主体视为在特定租户中使用的本地表示。应用程序对象充当模板,从该模板派生通用和默认属性以用于创建相应的服务主体对象。
-
因此,应用程序对象与软件应用程序具有 1:1 关系,与其对应的服务主体对象具有 1:many 关系。必须在使用应用程序的每个租户中创建服务主体,使其能够建立用于登录和/或访问由租户保护的资源的身份。
示例图
概括
现在,我们可以知道 Azure AD 应用程序密钥和服务原理密码之间的区别了。它们属于不同的对象。要与服务主体关联的密码。这仅适用于应用程序租户登录 azure。但是,您可以提供带有应用程序 ID 的 App 键值,以使用所有租户作为应用程序登录。
要查看有关 Azure Active Directory 中的应用程序和服务主体对象的更多详细信息,可以参考此文档。