Какая разница между родным приложением и веб-приложением в Azure Active Directory
Когда мы регистрируем приложение в Azure Active Directory для использования графика api, я вижу, что есть два типа приложений Web-приложения и собственное приложение.
При создании веб-приложения запрашиваются два значения: 1. URL входа и 2. URL-адрес идентификатора приложения. Какая польза от этих ценностей? Достаточно ли нам требуется URL-адрес реального мира или просто https://localhost:randomePort?
С другой стороны, создавая собственное приложение, я вижу только одно обязательное значение "URL-адрес переадресации".
Я могу получить токен доступа для веб-приложения, используя вызов REST
POST https://login.microsoftonline.com/<tenant-id>/oauth2/token
grant_type client_credentials
client_id (the client ID of the calling service application in the AD)
client secret (the key configured in the calling service application in the AD)
resource https://graph.windows.net
Но как я могу получить токен доступа для собственного приложения, используя такой вызов REST? потому что нет секретности клиента для встроенного приложения
Приступая к разрешениям, для собственного приложения я могу видеть только опцию делегированных разрешений, в то время как для веб-приложения я могу видеть разрешение приложения, а также делегированные разрешения.
Еще одна вещь, над примером вызова REST аутентифицирует приложение. Как я могу аутентифицировать пользователя, используя его учетные данные, используя вызов REST?
Ответы
Ответ 1
Собственные приложения являются общедоступными клиентами на языке OAuth2. Эти приложения предназначены для запуска на устройстве и не доверяются для сохранения секретности, поэтому их запись в каталоге не имеет соответствующего свойства. Без секретов нельзя утверждать идентичность приложения - поэтому такие приложения не могут получить разрешения на уровне приложений, и UX портала отражает это.
Напротив, веб-приложения, опять же на OAuth2 parlance, являются конфиденциальными клиентами. Они могут получать делегированные токены для своих пользователей, но они также могут использовать учетные данные клиента для получения токенов как самих себя.
Собственные приложения могут получить токены для пользователя через грант разрешения OAuth2. Полный обзор всех поддерживаемых топологий можно найти в https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/. Каждое описание сценария указывает на более ориентированное на реализацию руководство.
