Служба проверки подлинности службы с использованием Azure AD и WebAPI

Айв создал базовое веб-приложение .NET, которое использует Azure AD для идентификации. Все работает нормально, как и ожидалось, и все, что я украшаю с помощью [Authroize], защищено.

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

Я следил за этим руководством, в котором объясняется аутентификация сервис-сервис.

Служба для авторизация службы с помощью Azure AD

Используя это, мне удалось запросить токен

POST https://login.microsoftonline.com/{TENANTID}/oauth2/token
grant_type=client_credentials
&client_id={CLIENTID}
&client_secret={CLIENTSECRET}
&resource=https%3A%2F%mydirectory.onmicrosoft.com/myappname

Запустив это с почтальоном, я получаю Bearer access_token, так что выглядит хорошо.

Теперь, если я вызову свое веб-приложение в Postman с этим токеном-носителем в заголовке,

GET https://localhost:44392/api/booking
Authorization Bearer {access_token}

Я получаю ответ в формате HTML от одного из диалогов Microsoft. Кажется, что он просто переходит в цикл перенаправления, поэтому теперь я не понимаю, есть ли у меня проблема с конфигурацией в запросе токена или мое веб-приложение нужно настроить по-другому. В статье здесь упоминается что-то о разрешениях в файле манифеста, но я не понимаю, зачем это нужно?

введите описание ссылки здесь

введите описание изображения здесь

Некоторые дополнительные моменты

  • Мое веб-приложение и POST для токена используют один и тот же идентификатор клиента AD.
  • Я пробовал разные приложения AD для каждой функции (Web и Service-to-Service), но, похоже, это не имело никакого значения.
  • Если я просто выполняю стандартный вход в систему в браузере, конечная точка API разрешается, как и ожидалось.

Любая помощь приветствуется!

Обновления:

Мне удалось попробовать приложение Daemon .NET 4.5, и это сработало безупречно с использованием UseWindowsAzureActiveDirectoryBearerToken.

Служба демона для аутентификации службы в .NET 4.5

Однако в моем приложении .NET Core это промежуточное ПО недоступно, поэтому я попытался использовать промежуточное ПО JwtBearer, но все равно получаю запрос на вход.

app.UseJwtBearerAuthentication(new JwtBearerOptions
            {
                Audience = "https://localhost:44392",
                Authority = "https://login.microsoftonline.com/{TENANTNAME}.onmicrosoft.com"
            });

Как видите, я установил только 2 свойства в BearerOptions, но я считаю, что их должно было быть достаточно для [авторизации] моей конечной точки API.


asp.net azure-active-directory active-directory adal
person Raj    schedule 08.03.2017    source источник
comment
Не могли бы вы прояснить, на каком конкретном этапе процесса вы застряли? Похоже, вы успешно зарегистрировали клиентское и ресурсное приложение. Также похоже, что вы успешно получили токен доступа к своему ресурсу. У вас возникли проблемы с тем, чтобы ваш ресурс принял токен?   -  person Shawn Tabrizi    schedule 08.03.2017
comment
Да, именно здесь я застрял. Я бы предположил, что, поскольку в веб-приложении установлен тот же идентификатор клиента, access_token будет принят. На самом деле это может быть принято, но проблема в том, что он не выполняет «безголовую» авторизацию, что заставляет меня думать, что где-то у меня что-то не так?   -  person Raj    schedule 08.03.2017
comment
Вы используете промежуточное программное обеспечение для проверки токена? Какую конкретную ошибку выдает ваш веб-API?   -  person Shawn Tabrizi    schedule 09.03.2017
comment
Просто используйте стандартное промежуточное ПО OpenIDConnectAuthentication, которое настраивает Файл ›Новый проект› Использовать AD Identity. Фактическая проблема заключается в том, что он вызывает перенаправление на страницу входа в Microsoft, а не использует действительный access_token. Мне интересно, запросил ли я неправильный grant_type или что-то в этом роде?   -  person Raj    schedule 09.03.2017

Ответы (1)


arrow_upward
0
arrow_downward

POST https://login.microsoftonline.com/ {CLIENTID} / oauth2 / token

Во-первых, точка токена неверна, когда вы приобретаете токен, мы должны использовать tenantId вместо clientId.

И для устранения этой проблемы я предлагаю вам декодировать access_token с этого сайта, чтобы узнать, совпадает с Audience, который вы настраиваете в проекте веб-API.

person Fei Xue - MSFT    schedule 09.03.2017
comment
Вы правы - это была ошибка в моем сообщении выше, которое я отредактировал, поэтому на самом деле я использовал TENANTID. Интересно, что aud, который я получаю в ответ, выглядит правильно, но когда я на самом деле просматриваю его, он не найден? Он имеет формат https: // {DIRNAME} .onmicrosoft.com / {APPNAME}. Вы можете посоветовать? - person Raj; 09.03.2017
comment
Только что заметил, что на сайте проверки JWT написано Invalid Signature? Что вы имеете в виду, когда упоминаете «Аудитория»? Это URI идентификатора приложения? - person Raj; 09.03.2017
comment
Кроме того, я вижу некоторые старые образцы, в которых упоминается UseWindowsAzureActiveDirectoryBearerAuthentication, но я не могу получить доступ к этому в .NET Core - person Raj; 09.03.2017
comment
Недействительная подпись вызвана тем, что вы не предоставили открытый ключ для проверки подписи. Аудитория (https://localhost:44392), которую вы настраиваете в веб-API, не соответствует значению в токене (https://{DIRNAME}.onmicrosoft.com/{APPNAME}). Вам необходимо настроить значение aud утверждения (https://{DIRNAME}.onmicrosoft.com/{APPNAME}) для вашего проекта веб-API. - person Fei Xue - MSFT; 10.03.2017
comment
Где взять открытый ключ? Я вижу, что мой токен состоит из 3 частей, поэтому я подумал, что одна часть является ключом? (Извините, новичок в этом) В моем каталоге уже добавлен ответный URL-адрес localhost: 44392. Как настроить заявку? У вас есть образцы кода, поскольку это отлично работает с UseWindowsAzureActiveDirectoryBearerAuthentication (поэтому я думаю, что мой каталог и конфигурация приложения в порядке), но, похоже, не работает с новыми библиотеками? - person Raj; 10.03.2017
comment
Эта проблема не связана с открытым ключом. Мы не можем настроить Заявление, которое выдается поставщиком удостоверений, например Azure AD. Нам просто нужно убедиться, что конфигурация аудитории в проекте веб-API может соответствовать заявлению aud в токене. Когда мы получаем токен, нам необходимо предоставить параметр ресурса, который будет выдан в качестве утверждения aud в токене доступа. И вы можете сослаться на образец кода здесь о безопасности веб-API для ядра .Net. - person Fei Xue - MSFT; 15.03.2017
comment
Мне удалось получить токен, есть ли способ или URL-адрес, по которому я могу расшифровать токен, чтобы получить client_id - person Anonymous; 19.08.2019