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

Question

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

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

[Update]

Из ссылки Джой на глоссарий, который я вижу

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

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

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

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

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

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

Это концепция «регистрации приложения» как клиента, к которой у меня возникают проблемы с привыканием. Я прошу помощи в понимании выбора слов.

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

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

1,1. Роли

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

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

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

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

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

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

Однако это все еще сбивает с толку.

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

Что означает «создание защищенного запроса ресурса от имени владельца ресурса»?

[Update]

Изучив ответ Уэйна Янга, я нашел эту картинку на страница Слэка оаут

Answer 1

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

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

Надеюсь, это обеспечит ясность для многих, кто все еще в замешательстве.

Answer 2

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

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

Это имя ближе к значению самого приложения. E.g. Собственный клиент может быть вызван с клиентом, но Web App / 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 :

Клиент: родное приложение

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

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

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

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

Answer 3

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

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

и

TenantId = DirectoryId = Имя или Guid вашей Azure Active Directory