在 Azure 中,为什么 AuthClientId 也称为应用程序 ID?

In Azure, why is an AuthClientId also called an Application Id?

我发现 Azure 中的应用程序注册非常混乱。 在我的 中,AuthClientId 和 Application Id 原来是同一个东西,为什么要使用两个名称?

这种命名选择背后的逻辑是什么?

[更新]

从Joy的link到我看到的词汇表

应用程序 ID(客户端 ID)

”Azure AD 颁发给应用程序注册的唯一标识符,用于标识特定应用程序和相关配置。此应用程序 ID(客户端 ID)在执行身份验证请求时使用,并在开发时提供给身份验证库。 “

我在 ietf.org 的页面上看到客户端 ID link 哪个州

"2.2. 客户端标识符

授权服务器向注册客户端颁发客户端 identifier -- 代表注册的唯一字符串 客户提供的信息。"

我猜这个比喻是关于供应商、客户、产品的关系 其中供应商是Active Directory,产品是身份验证,客户是应用程序注册。

作为客户,“申请注册”的概念让我不太习惯。我在理解选词方面寻求帮助。

多租户应用程序的想法并不真正适用于“客户端”比喻。

[更新] 这个link is the most helpful yet也是最权威的 从 link

复制

1.1. Roles

OAuth 定义了四种角色:

资源所有者 能够授予对受保护资源的访问权限的实体。 当资源所有者是一个人时,它被称为 最终用户。

资源服务器 托管受保护资源的服务器,能够接受 并使用访问令牌响应受保护的资源请求。

客户 一个应用程序代表 资源所有者及其授权。 “客户”一词确实 不暗示任何特定的实现特征(例如, 应用程序是在服务器、桌面还是其他平台上执行 设备)。

授权服务器 服务器成功后向客户端颁发访问令牌 验证资源所有者并获得授权。

授权服务器与资源的交互 服务器超出了本规范的范围。这 授权服务器可能与资源服务器是同一台服务器 或一个单独的实体。单个授权服务器可能会发出 多个资源服务器接受的访问令牌。

然而还是一头雾水

“代表资源所有者并经其授权发出受保护资源请求的应用程序”

“代表资源所有者发出受保护的资源请求”是什么意思?

[更新]

研究了 Wayne Yang 的回答后,我在 Slack's oauth page 找到了这张图片

在 Azure 中,要创建服务主体,您必须注册一个应用程序。这就是为什么它被称为应用程序 ID (AppId)。所以:

AppId = ClientId = AuthClientId = 您的应用程序 ID

TenantId = DirectoryId = Azure Active Directory 的名称或 Guid

这里的客户端 ID 主题中出现混淆的原因是:

Azure 旧门户 (https://manage.windowsazure.com) they mention the “Client ID” as “Client ID ” and when it comes to the Azure new portal (http://portal.azure.com) 中,他们提供“应用程序 ID”和“对象 ID”,所以这里通常会引起混淆,许多人可能会复制“对象 ID”作为“客户端 ID”,但在新门户中我们需要复制“应用程序 ID”作为我们的“客户端 ID”。

希望这能为许多仍然感到困惑的人提供清晰的思路。

why is an AuthClientId also called an Application Id?

Client IdOAuth2.0 protocol中的标准定义。也是实际应用。 Application Id 只是 Azure 门户中的另一个名称。

这个名字更接近应用本身的意思。 E.g Native Client可以用客户端调用,但是WebApp/Api其实是一个服务端服务,运行在服务器端。但都是应用。

所以Application id 对普通用户来说更有意义。但是 client Id 是标准定义,您无法更改它。

What does it mean by "making a protected resource request on behalf of the resource owner"?

表示客户端可以代表用户请求access token,并将access token发送给Resource。 (如果让用户自己做,既不安全又复杂)

在OAuth2.0框架中,客户端是用户(资源所有者)、应用程序(受保护资源)和身份提供者(授权服务器)的桥梁。如果一个用户想要访问 SaaS 应用程序,他将向客户端发送授权请求,而不是直接向授权服务器发送授权请求。然后客户端可以代表用户向授权服务器请求访问令牌并将访问令牌发送到应用程序。

协议流程如下:

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

  

CF,客户端代表资源所有者获取访问令牌并发送访问令牌。

对于 AAD,Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow 有一个文档:

客户端:本机应用程序

资源:网络API

资源所有者:用户

授权服务器:AAD

这里的Native app是代表用户请求token并将token发送给资源的客户端。