Azure активный каталог с двойным согласием, недетерминирован c поток - PullRequest
Новая
       3

Azure активный каталог с двойным согласием, недетерминирован c поток

0 голосов
/ 05 февраля 2020

У меня есть регистрация приложения в Azure со следующими настроенными разрешениями:

Azure app registation permissions

Из моего приложения я запускаю поток oauth с следующий URL (отредактированные параметры с XXXXXXX): 

https://login.microsoftonline.com/common/oauth2/authorize
     ?client_id=XXXXXXX
     &grant_type=client_credentials
     &redirect_uri=XXXXXXX
     &resource=https%3A%2F%2Foutlook.office365.com
     &response_type=code&scope=openid+email+profile+full_access_as_app
     &state=XXXXXXX

Мой пользователь дважды получает один и тот же экран согласия (обратите внимание на разные URL):

first consent screen

, а затем:

second consent screen

Затем они перенаправляются на redirect_url.

В обратном вызове большинство я получаю: 

access_denied | AADSTS650051: Claim is invalid: User.Read does not exist in client application's RequiredResourceAccess.

И приложение не добавляется в список авторизованных приложений для пользователя в Azure Portal.

Однако иногда поток работает.

Что, по-видимому, является важной частью манифеста приложения: 

"oauth2Permissions": [
    {
      "adminConsentDescription": "Allow the application to access XXXXXX on behalf of the signed-in user.",
      "adminConsentDisplayName": "Access XXXXXX",
      "id": "XXXXXX",
      "isEnabled": true,
      "lang": null,
      "origin": "Application",
      "type": "User",
      "userConsentDescription": "Allow the application to access XXXXXX on your behalf.",
      "userConsentDisplayName": "Access XXXXXX",
      "value": "user_impersonation"
    }
  ],

Вопросы:

  1. Почему они дважды получают один и тот же диалог согласия? Могу ли я избежать этого?
  2. Есть идеи, что может быть не так с моей установкой, и поток работает недетерминированно?

Ответы [ 2 ]

1 голос
/ 06 февраля 2020

Вчера я воспроизвел вашу проблему, но сегодня она работает без каких-либо изменений. Вы можете попробовать еще раз. Если эта проблема все еще существует, просто дайте мне знать.

Кстати, параметр grant_type в URL-адресе аутентификации не требуется, вы можете взглянуть на ответ @ junnas.

Ссылка:

Различия между разрешениями приложений и делегированными разрешениями

1 голос
/ 05 февраля 2020

читая ваш ответ еще раз, возможно, у вас не было проблем с вещами, которые я упомянул. Но я оставлю это здесь на случай, если это все равно поможет. Пожалуйста, прокомментируйте, если у вас есть дополнительные вопросы

Ваша конфигурация и URL выглядят странно. Вы хотите получить доступ к API как пользователь или как приложение? В настоящее время у вас есть оба.

Ваш URL-адрес авторизации устанавливает тип предоставления для учетных данных клиента, что не имеет смысла (честно говоря, я ожидаю, что AAD выдаст ошибку, но я предполагаю, что тип ответа кода заставляет его использовать поток кода авторизации) , Учетные данные клиента являются чисто внутренним потоком и не включают пользователей, поэтому их не следует использовать при перенаправлении.

Если вы хотите правильно использовать разрешение приложения, вам нужно упростить свой подход , Вот документы для потока учетных данных клиента с конечной точкой v2: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow. Если ваше приложение является мультитенантным, вам нужно будет дать согласие на ваше приложение, как вы делаете сейчас, прежде чем вы сможете реально использовать поток. Но, если он используется только в вашей организации, вы (или администратор) можете согласиться с вашими разрешениями на портале, и вы можете сразу использовать поток.

Вы получаете токен с помощью HTTP-вызова, включая учетные данные вашего приложения + то, для чего вы хотите токен. В версии v2 здесь должна быть указана URI идентификатора приложения / идентификатора приложения для Exchange + .default. Я не смог найти подходящую ссылку для этого в отношении Exchange с помощью быстрого поиска в Google, но я попытаюсь проверить еще раз, когда у меня откроется компьютер.

...