Управление API Azure с помощью OAuth2.0 и входа в систему AAD вызывает повторный цикл

#azure-active-directory #azure-api-management #azure-authentication #microsoft-identity-web

Вопрос:

У нас есть простое веб-приложение, и я пытаюсь использовать управление API Azure поверх него. Прямо сейчас я перенаправляю CName нашего продукта веб-приложения на URL-адрес apim.

Наше веб-приложение является сторонним приложением, и оно выполняет проверку подлинности AAD из Microsoft.Identity.Web пакета nuget и получает ключ доступа, как показано ниже:

 string accessToken = tokenAcquisition.GetAccessTokenForUserAsync(new[] { Configuration["Scopes:<product>"] }).GetAwaiter().GetResult();

Прямо сейчас я перенаправляю весь трафик (GET /* и POST /*) с CName на URL apim

Без использования APIM наши сетевые вызовы (успешные) выглядят следующим образом: Без APIM

Однако при добавлении уровня APIM наши сетевые вызовы выглядят следующим образом: С APIM

Каким-то образом /signin-oidc запрос перенаправляет вызов login.microsoftonline.com/.. вместо авторизации запроса и перенаправления обратно в корневой каталог (путь: '/' ) страницы вызывающего абонента.

Мы получаем повторяющийся цикл:

 apim-url => login.microsoftonline.com/consumers/.. => login.live.com/... => apim-url/signin-oidc =>  login.microsoftonline.com/consumers => ...

Я не уверен, работает ли перенаправление неправильно или аутентификация не работает.

Любые зацепки были бы полезны,

Спасибо,

Маниша

Ответ №1:

Я не знаю, почему у вас такое поведение, но часто цикл аутентификации происходит из-за плохого перенаправления.

Вы используете перенаправление dns, поэтому вам следует добавить в AAD URL-адрес перенаправления 2 на портале :

apim-url/подпись-oidc и [домен пользователя]/подпись-oidc

1. Спасибо за предложение, но у нас уже есть это, без этого мы получили ошибку «Неверный uri перенаправления»

2. Извините за это, вы использовали CDN или какой-то прокси-сервер ?

3. Нет, мы не используем какой-либо прокси-сервер, просто позволяя apim перенаправлять на наш размещенный URL.

4. Последнее, о чем я мог думать, — это ошибка секретного ключа или неправильная конфигурация в AAD для приложения…

5. Ваша архитектура выглядела так же, как эта ? : docs.microsoft.com/en-us/azure/architecture/…

Ответ №2:

Я просто пробую это с нуля :

Создайте службу управления API azure
Добавьте шлюз-давайте назовем его «мой шлюз».
Добавьте Api (я выбираю функцию Azure с аутентификацией AAD), назовите ее «my-api».
В настройках API (API => мой-api =>> Настройки) Я удаляю запрошенную подписку (только для теста) и не проверяю Наличие авторизации пользователя (потому что в моем тесте за это отвечает моя функция, а не шлюз).

Теперь я тестирую в своем Http-клиенте (для меня это клиент Advanced REST) вызов шлюза :

https://my-gateway.azure-api.net/my-api

В заголовке я добавляю : Авторизация : Предъявитель [xxxx — Токен безопасности]

Если все настройки AAD в порядке , это будет работать нормально (для меня это работает).

Если нет, то ваш pb находится в конфигурации AAD вашего api (или в какой-то плохой реализации AuthO/OpenID внутри вашего кода API).

Если возможно, поделитесь с нами частью вашего кода для обеспечения безопасности в вашем API.