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

Защита API в службе "Управление API" Azure с помощью авторизации OAuth 2.0 в Microsoft Entra ID

  • Статья

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

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

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

Необходимые компоненты

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

  • Экземпляр управления API.
  • Опубликованный API (с помощью экземпляра Управления API).
  • Клиент Microsoft Entra

Обзор

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

  1. Зарегистрируйте приложение (вызываемое серверное приложение в этой статье) в идентификаторе Microsoft Entra для защиты доступа к 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-config aad-tenant — это идентификатор клиента в идентификаторе Microsoft Entra. Найдите это значение в портал Azure, например на странице обзора ресурса Microsoft Entra. В приведенном примере предполагается однотенантное приложение Microsoft Entra и конечная точка конфигурации версии 2.
  • Значением claim является идентификатор клиента серверного приложения, зарегистрированного в идентификаторе Microsoft Entra.
<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 с разрешениями, предоставляющими доступ к внутреннему приложению.

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

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

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

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

Следующие шаги