В Azure, почему AuthClientId также называется идентификатором приложения?

Я считаю, что регистрация приложений в Azure очень запутанна. В моем вопросе здесь AuthClientId и Application Id оказались одинаковыми, так почему используются два имени?

Какова логика этого выбора именования?

[Обновить]

От ссылки Джой к глоссарию я вижу

идентификатор приложения (идентификатор клиента)

"Уникальный идентификатор Azure AD вызывает регистрацию приложения, которая идентифицирует конкретное приложение и связанные с ним конфигурации. Этот идентификатор приложения (идентификатор клиента) используется при выполнении запросов аутентификации и предоставляется библиотекам проверки подлинности во время разработки".

Я вижу, что идентификатор клиента ссылается на страницу на ietf.org.

2.2. Идентификатор клиента

Сервер авторизации выдает зарегистрированному клиенту идентификатор клиента - уникальную строку, представляющую регистрационную информацию, предоставленную клиентом ".

Я предполагаю, что метафора касается поставщика, клиента, продукта. Когда поставщик является Active Directory, продукт является аутентификацией, а клиент является регистрацией приложения.

Это концепция "регистрации приложений" в качестве клиента, с которой мне трудно привыкать. Я ищу помощь в понимании выбора слов.

Идея приложения с несколькими арендаторами действительно не работает с "клиентской" метафорой.

[Обновить] Эта ссылка является наиболее полезной и наиболее авторитетной Копирование из ссылки

1.1. Роли

OAuth определяет четыре роли:

владелец ресурса Сущность, способная предоставить доступ к защищенному ресурсу. Когда владельцем ресурса является человек, он упоминается как конечный пользователь.

сервер ресурсов Сервер, на котором размещены защищенные ресурсы, способные принимать и отвечать на защищенные запросы ресурсов с помощью токенов доступа.

клиент Приложение, защищающее запросы ресурсов от имени владельца ресурса и с его авторизацией. Термин "клиент" не подразумевает каких-либо конкретных характеристик реализации (например, выполняется ли приложение на сервере, на рабочем столе или на других устройствах).

сервер авторизации Сервер выдаёт токены доступа клиенту после успешной аутентификации владельца ресурса и получения авторизации.

Взаимодействие между сервером авторизации и сервером ресурсов выходит за рамки этой спецификации. Сервер авторизации может быть тем же сервером, что и сервер ресурсов или отдельный объект. Один сервер авторизации может выдавать токены доступа, принятые несколькими серверами ресурсов.

Однако это все еще запутывает.

"Приложение, создающее защищенные запросы ресурсов от имени владельца ресурса и с его авторизацией",

Что это означает, "сделав защищенный запрос ресурсов от имени владельца ресурса"?

[Обновить]

Изучив ответ Уэйна Янга, я нашел эту фотографию на странице Slack oauth OAuth 2.0 authorization code grant flow

Ответы

Ответ 1

почему AuthClientId также называется идентификатором приложения?

Client Id является стандартным определением в протоколе OAuth2.0. Это тоже актуальное приложение. Application Id - это еще одно имя на Azure Portal.

Это имя больше похоже на приложение. Например, Native Client может быть вызван с клиентом, но веб-приложение /Api на самом деле является серверной службой, которая работает на сервере. Но это все приложения.

Таким образом, идентификатор приложения лучше иметь смысл для обычных пользователей. Но client Id - это стандартное определение, которое вы не можете изменить.

Что это означает, "сделав защищенный запрос ресурсов от имени владельца ресурса"?

Это означает, что клиент может от имени пользователей запрашивать токен доступа и отправлять токен доступа в ресурс. (Если вы позволяете пользователям делать это сами по себе, это небезопасно и сложно)

В среде 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 ---|               |
 +--------+                               +---------------+

От C до F Клиент от имени владельца ресурса получает маркер доступа и передает токен доступа.

Для AAD существует документ для авторизации доступа к веб-приложениям Azure Active Directory с использованием потока предоставления кода OAuth 2.0:

enter image description here

Клиент: собственное приложение

Ресурс: веб-API

Владелец ресурса: пользователь

Сервер авторизации: AAD

Здесь приложение Native - это клиент, который от имени пользователя запрашивает токен и отправляет токен ресурсу.

Ответ 2

В Azure для создания Принципа Сервиса вам необходимо зарегистрировать Приложение. Вот почему его назвал Application Id (AppId). Так:

AppId = ClientId = AuthClientId = Id вашего приложения

а также

TenantId = DirectoryId = имя или руководство вашего Azure Active Directory

Ответ 3

Почему возникает путаница в теме идентификатора клиента:

На старом портале Azure (https://manage.windowsazure.com) они упоминают "Идентификатор клиента" как "Идентификатор клиента", и когда дело доходит до нового портала Azure (http://portal.azure.com), они предоставляют "Идентификатор приложения", а также "Идентификатор объекта", поэтому здесь начинается путаница, и многие из них могут копировать "Идентификатор объекта" как "Идентификатор клиента", но на новом портале нам нужно скопировать "Идентификатор приложения" в качестве нашего "Клиента" Я БЫ".

Надеюсь, что это дает ясность тем, у кого еще есть путаница.