Перенаправляет ли APIM один и тот же токен-носитель в серверный API? | OAuth 2.0 и Azure AAD

Следуя приведенному ниже документу, предоставленному Microsoft, я зарегистрировал оба приложения, настроил службу OAuth 2.0 с учетными данными клиента и добавил входящую политику validate-jwt. Я тестировал его с помощью почтальона, генерирующего токен-носитель и вызывающего мой серверный API под экземпляром APIM, передающим токен. Работает нормально.

https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad

Но вместе с Apim я хочу также защитить свой серверный API и передать тот же токен на серверный API. так что у меня есть несколько вопросов -

  • Перенаправляет ли APIM один и тот же токен-носитель автоматически на серверный API или нам нужно настроить для него какую-либо политику?
  • Если да, как я могу проверить журналы трассировки? Также как я могу авторизовать тот же токен в коде серверного API?

Вот моя политика validate-jwt -

<inbound>
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
        <openid-config url="https://login.microsoftonline.com/{AAD Tenant ID}/v2.0/.well-known/openid-configuration" />
        <audiences>
            <audience>{App Id of backend App}</audience>
        </audiences>
    </validate-jwt>
    <base />
</inbound>

Пожалуйста помоги.


person Rahul    schedule 12.03.2021    source источник


Ответы (1)


По первому вопросу:

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

Я создал api в APIM для вызова api графа microsoft (список пользователей) в бэкэнде. Тест для запуска APIM api, он показывает 401 неавторизованную ошибку. Затем я тестирую, предоставляя токен-носитель в заголовках APIM api, как показано на скриншоте ниже:  введите описание изображения здесь

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

По второму вопросу:

Если вы хотите отслеживать журналы для backend api, я думаю, вы можете просто сделать это в коде backend вашего api.

Чтобы проверить токен в своем внутреннем API, вы можете декодировать токен jwt в своем внутреннем коде API, а затем проверить значение утверждения в токене (ниже я предоставляю образец для декодирования токена jwt и получения значения iss утверждения)

using System;
using System.Collections.Generic;
using System.IdentityModel.Tokens.Jwt;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp5
{
    class Program
    {
        static void Main(string[] args)
        {
            var stream = "your access token";
            var handler = new JwtSecurityTokenHandler();
            var jsonToken = handler.ReadToken(stream);
            var tokenS = handler.ReadToken(stream) as JwtSecurityToken;

            var iss = tokenS.Claims.First(claim => claim.Type == "iss").Value;
            Console.WriteLine(iss);
            //Then check if "iss" matches the value you specified.

            Console.ReadLine();
        }
    }
}

person Hury Shen    schedule 12.03.2021
comment
Привет @Hury, Спасибо за ответ. Для вашего первого ответа: как вы можете быть уверены, что токен проверяется с помощью внутреннего API или APIM? Я просто хотел проверить, есть ли у вас какие-либо журналы трассировки, в которых вы могли бы найти тот же токен в запросе к внутреннему API? - person Rahul; 13.03.2021
comment
Привет, @Rahul, я не знаю, как отследить токен, когда он запрашивает backend api. В моем тесте токен-носитель генерируется для backend api перед тестом. Я добавляю токен в заголовок запроса, когда я вызываю APIM api, если токен не был проверен серверным API, он ответит сообщением об ошибке. В настоящее время он отвечает на успех списка пользователей, поэтому я думаю, что токен был отправлен на серверный API и прошел проверку. - person Hury Shen; 13.03.2021
comment
Привет @Hury, Спасибо за ответ. Я попробую так же. - person Rahul; 15.03.2021
comment
Привет, @Rahul. Могу я узнать, решили ли вы эту проблему? - person Hury Shen; 16.03.2021