Поделиться через


Защита API в Azure API Management с использованием авторизации OAuth 2.0 через Microsoft Entra ID

ОБЛАСТЬ ПРИМЕНЕНИЯ: управление API всех уровней

В этой статье вы узнаете, как настроить экземпляр Azure API Management для защиты API с использованием протокола OAuth 2.0 и Microsoft Entra ID.

Общие сведения о авторизации API см. в разделе "Проверка подлинности и авторизация в API" в Управление API.

Предварительные требования

Чтобы выполнить шаги в этой статье, необходимо иметь следующее:

  • Система управления экземпляром API.
  • Опубликованный API в экземпляре API Management.
  • Клиент Microsoft Entra

Обзор

Выполните следующие действия, чтобы защитить API в Управлении API, используя авторизацию OAuth 2.0 с Microsoft Entra ID.

  1. Зарегистрируйте приложение (называемое backend-app в этой статье) в Microsoft Entra ID для защиты доступа к API.

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

  2. Настройте политику validate-jwt в Управлении API для проверки маркера OAuth, представленного в каждом входящем запросе API. Допустимые запросы можно передать в API.

Сведения о потоках авторизации OAuth и способах создания необходимых маркеров OAuth не рассматриваются в этой статье. Как правило, отдельное клиентское приложение используется для получения маркеров из идентификатора Microsoft Entra, который авторизует доступ к API. Ссылки на дополнительные сведения см. в связанном содержимом.

Регистрация приложения в идентификаторе Microsoft Entra для представления API

Используя портал Azure, защитите API с помощью идентификатора Microsoft Entra, сначала зарегистрируя приложение, представляющее API.

Дополнительные сведения о регистрации приложений см. в разделе Краткое руководство. Настройка приложения для предоставления доступа к веб-API.

  1. На портале Azure найдите и выберите Регистрация приложений.

  2. Выберите Создать регистрацию.

  3. Когда появится страница Регистрация приложения, введите регистрационную информацию приложения:

    • В разделе Имя введите понятное имя приложения, которое будет отображаться пользователям приложения, например backend-app.
    • В разделе Поддерживаемые типы учетных записей выберите вариант, который подходит для вашего сценария.
  4. Оставьте раздел URI перенаправления пустым.

  5. Выберите Зарегистрировать, чтобы создать приложение.

  6. На странице приложения Обзор найдите идентификатор приложения (клиента) и запишите его, чтобы использовать позже.

  7. В разделе Управление бокового меню выберите Предоставление API и задайте для параметра URI идентификатора приложения значение по умолчанию. Если вы разрабатываете отдельное клиентское приложение, чтобы получать маркеры OAuth 2.0 для доступа к серверному приложению, запишите это значение.

  8. Нажмите кнопку Добавить область, чтобы открыть страницу Добавление области:

    1. Введите новое имя области действия, название для отображения согласия администратора и описание согласия администратора.
    2. Убедитесь, что выбрано состояние области Включено.
  9. Нажмите кнопку Добавить область, чтобы создать область.

  10. Повторите предыдущие два шага, чтобы добавить все области, поддерживаемые API.

  11. Созданные области понадобятся позже.

Настройка политики проверки JWT для запросов предварительной авторизации

В следующем примере политики при добавлении <inbound> в раздел политики проверяется значение утверждения аудитории в маркере доступа, полученном от идентификатора Microsoft Entra, представленного в заголовке авторизации. Он возвращает сообщение об ошибке, если маркер не действителен. Настройте эту политику в области политики, соответствующей вашему сценарию.

  • В URL-адресе openid-configaad-tenant — это идентификатор клиента в идентификаторе Microsoft Entra. Найдите это значение в портале Azure, например, на странице обзора ресурса Microsoft Entra. В приведенном примере предполагается однотенантное приложение Microsoft Entra и конечная точка конфигурации версии 2.
  • Значение claim — это идентификатор клиента серверного приложения, который вы зарегистрировали в Microsoft Entra ID.
<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}/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>{audience-value - (ex:api://guid)}</audience>
    </audiences>
    <issuers>
        <issuer>{issuer-value - (ex: https://sts.windows.net/{tenant id}/)}</issuer>
    </issuers>
    <required-claims>
        <claim name="aud">
            <value>{backend-app-client-id}</value>
        </claim>
    </required-claims>
</validate-jwt>

Примечание.

Указанный выше URL-адрес openid-config соответствует конечной точке версии 2. Для конечной точки версии 1 openid-config используйте https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration.

Сведения о настройке политик см. в статье How to set or edit Azure API Management policies (Как настроить или изменить политики в службе управления API Azure). Для дополнительной настройки проверки JWT см. справочник по validate-jwt. Чтобы проверить JWT, предоставляемый службой Microsoft Entra, Управление API также предоставляет validate-azure-ad-token политику.

Рабочий процесс авторизации

  1. Пользователь или приложение получает токен от Microsoft Entra ID с разрешениями, предоставляющими доступ к бэкэнд-приложению. Если вы используете конечную точку версии 2, убедитесь, что свойство accessTokenAcceptedVersion имеет значение 2 в манифесте приложения серверной части и любом клиентском приложении, настроенном.

  2. Токен добавляется в заголовок авторизации запросов к Управлению API.

  3. Управление API проверяет маркер с помощью политики validate-jwt.

    • Если у запроса нет допустимого маркера, Управление API заблокирует его.

    • Если запрос сопровождается допустимым токеном, шлюз может перенаправить запрос к API.