Проверка подлинности и авторизация для API в "Управление API" Azure

  • Статья

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

В этой статье представлен широкий гибкий набор функций в Управление API, которые помогают защитить доступ пользователей к управляемым API.

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

Схема, показывающая точки взаимодействия для защиты API.

Управление API поддерживает другие механизмы проверки подлинности на стороне клиента и службы, которые дополняют OAuth 2.0 или полезны, если авторизация OAuth 2.0 для API невозможна. Выбор из этих вариантов зависит от зрелости среды API вашей организации, требований к безопасности и соответствию требованиям и подходу вашей организации к устранению распространенных угроз API.

Внимание

Защита доступа пользователей к API является одним из многих аспектов защиты среды "Управление API". Для получения дополнительных сведений см. статью Базовые показатели безопасности Azure для "Управления API".

Примечание.

Другие компоненты Управление API имеют отдельные механизмы для защиты и ограничения доступа пользователей:

  • Для управления экземпляром Управление API с помощью плоскости управления Azure Управление API используется идентификатор Microsoft Entra и управление доступом на основе ролей Azure (RBAC).
  • Портал разработчика Управление API поддерживает несколько вариантов для упрощения безопасной регистрации и входа пользователей.

Сравнение проверки подлинности и авторизации

Ниже приведено краткое описание аутентификации и авторизации в контексте доступа к API.

  • Аутентификация — процесс проверки удостоверения пользователя или приложения, обращающегося к API. Аутентификация может быть выполнена с помощью учетных данных, таких как имя пользователя и пароль, сертификат, а также с помощью единого входа (SSO) или других методов.

  • Авторизация — процесс определения того, имеет ли пользователь или приложение разрешение на доступ к определенному API, часто через протокол на основе маркеров, например OAuth 2.0.

Примечание.

В дополнение к аутентификации и авторизации доступ к API также должен быть защищен с помощью TLS для защиты учетных данных или маркеров, используемых для аутентификации или авторизации.

Основные понятия OAuth 2.0

OAuth 2.0 — это стандартная платформа авторизации, которая широко используется для защиты доступа к ресурсам, таким как веб-API. OAuth 2.0 ограничивает действия, которые клиентское приложение может выполнять от имени пользователя, не используя учетные данные пользователя. Хотя OAuth 2.0 не является протоколом проверки подлинности, он часто используется с OpenID Подключение (OIDC), который расширяет OAuth 2.0, предоставляя функциональность проверки подлинности пользователей и единого входа.

Поток OAuth

Что происходит, когда клиентское приложение вызывает API с запросом, защищенным с помощью TLS и OAuth 2.0? Ниже приведен сокращенный пример процесса:

  • Клиент (вызывающее приложение или носитель) выполняет проверку подлинности с помощью учетных данных для поставщика удостоверений.

  • Клиент получает ограниченный по времени маркер доступа (веб-маркер JSON или JWT) с сервера авторизации поставщика удостоверений.

    Поставщик удостоверений (например, идентификатор Microsoft Entra) является издателем маркера, а маркер включает утверждение аудитории, которое разрешает доступ к серверу ресурсов (например, к внутреннему API или к самому шлюзу Управление API).

  • Клиент вызывает API и представляет маркер доступа, например, в заголовке авторизации.

  • Сервер ресурсов проверяет маркер доступа. Проверка — это сложный процесс, включающий проверку того, что утверждения издателя и аудитории содержат ожидаемые значения.

  • На основе критериев проверки маркеров доступ к ресурсам внутреннего API затем предоставляется.

В зависимости от типа клиентского приложения и сценариев для запроса маркеров и управления ими требуются различные потоки авторизации. Например, поток кода авторизации и тип предоставления разрешения обычно используются в приложениях, которые вызывают веб-API. Дополнительные сведения о потоках OAuth и сценариях приложений см. в идентификаторе Microsoft Entra.

Сценарии авторизации OAuth 2.0 в Управление API

Сценарий 1. Клиентское приложение авторизует непосредственно серверную часть

Распространенный сценарий авторизации заключается в том, что вызывающие приложения запрашивают доступ к внутреннему API напрямую и представляют маркер OAuth 2.0 в заголовке авторизации шлюзу. Затем Azure Управление API выступает в качестве прозрачного прокси-сервера между вызывающим и серверным API, а маркер передается без изменений в серверную часть. Область маркера доступа находится между вызывающим приложением и API серверной части.

На следующем рисунке показан пример, в котором идентификатор Microsoft Entra является поставщиком авторизации. Клиентское приложение может быть одностраничным приложением (SPA).

Диаграмма, на которой показан обмен данными OAuth, где аудиторией является серверная часть.

Хотя маркер доступа, отправляемый вместе с HTTP-запросом, предназначен для внутреннего API, Управление API по-прежнему обеспечивает защиту в глубинном подходе. Например, настройте политики для проверки JWT, отклоняя запросы, поступающие без маркера, или маркер, недопустимый для предполагаемого серверного API. Вы также можете настроить службу Управление API для проверки других интересующих утверждений, извлеченных из маркера.

Примечание.

Если вы защищаете API, предоставляемый с помощью Azure Управление API с помощью OAuth 2.0, вы можете настроить Управление API для создания допустимого маркера для тестирования от имени пользователя тестовой консоли портал Azure или портала разработчика. Необходимо добавить сервер OAuth 2.0 в экземпляр Управление API и включить параметры авторизации OAuth 2.0 в API. Дополнительные сведения см. в статье "Авторизация тестовой консоли портала разработчика", настроив авторизацию пользователя OAuth 2.0.

Пример:

Совет

В особых случаях, когда доступ к API защищен с помощью идентификатора Microsoft Entra, можно настроить политику маркера validate-azure-ad-token для проверки маркеров .

Сценарий 2. Клиентское приложение разрешает Управление API

В этом сценарии служба Управление API действует от имени API, а вызывающее приложение запрашивает доступ к экземпляру службы Управление API. Область маркера доступа между вызывающим приложением и шлюзом Управление API. В Управление API настройте политику (validate-jwt или validate-azure-ad-token), чтобы проверить маркер, прежде чем шлюз передает запрос серверной части. Отдельный механизм обычно защищает подключение между шлюзом и серверным API.

В следующем примере идентификатор Microsoft Entra снова является поставщиком авторизации, а взаимная проверка подлинности TLS (mTLS) защищает соединение между шлюзом и серверной частью.

Диаграмма, на которой показан обмен данными OAuth, где аудиторией является шлюз службы Управление API.

Есть разные причины для этого. Например:

  • Серверная часть — это устаревший API, который не может быть обновлен для поддержки OAuth

    Службу Управление API сначала следует настроить для проверки маркера (как минимум проверки утверждений издателя и аудитории). После проверки используйте один из нескольких вариантов, доступных для защиты исходящих подключений от Управление API, таких как взаимная проверка подлинности TLS (mTLS). См . раздел "Параметры на стороне службы" далее в этой статье.

  • Контекст, необходимый серверной части, невозможно установить из вызывающего объекта.

    После успешной проверки маркера, полученного от вызывающего клиента, службе Управление API необходимо получить маркер доступа для серверного API с помощью собственного контекста или контекста, полученного из вызывающего приложения. Этот сценарий можно реализовать с помощью следующих средств:

    • Настраиваемая политика, например отправка запроса для получения маркера доступа, допустимого для внутреннего API от настроенного поставщика удостоверений.

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

  • Организация хочет принять стандартизированный подход к авторизации

    Независимо от механизмов проверки подлинности и авторизации в серверных службах API организации могут выбрать конвергироваться в OAuth 2.0 для стандартизированного подхода авторизации на интерфейсе. шлюз Управление API может включить согласованную конфигурацию авторизации и общий интерфейс для потребителей API по мере развития серверной части организации.

Сценарий 3. Управление API авторизует серверную часть

С управляемыми подключениями (ранее называемыми авторизациями) вы используете диспетчер учетных данных в Управление API для авторизации доступа к одной или нескольким службам SaaS, таким как LinkedIn, GitHub или другие серверные серверные серверы, совместимые с OAuth 2.0. В этом сценарии пользователь или клиентское приложение выполняет запрос к шлюзу Управление API с доступом шлюза, контролируемым с помощью поставщика удостоверений или других параметров на стороне клиента. Затем с помощью конфигурации политики пользователь или клиентское приложение делегирует серверную проверку подлинности и авторизацию для Управление API.

В следующем примере ключ подписки используется между клиентом и шлюзом, а GitHub — поставщик учетных данных для внутреннего API.

Схема, показывающая авторизацию для серверной службы SaaS с помощью подключения, управляемого в диспетчере учетных данных.

При подключении к поставщику учетных данных Управление API получает и обновляет маркеры доступа к API в потоке OAuth 2.0. Подключение ions упрощают управление маркерами в нескольких сценариях, например:

  • Клиентское приложение может потребоваться авторизовать несколько серверных серверных компонентов SaaS для разрешения нескольких полей с помощью сопоставителей GraphQL.
  • Пользователи проходят проверку подлинности в Управление API по единому входу из поставщика удостоверений, но авторизуют серверный поставщик SaaS (например, LinkedIn) с помощью общей учетной записи организации.
  • Клиентское приложение (или бот) должно получить доступ к защищенным сетевым ресурсам серверной части от имени прошедшего проверку подлинности пользователя (например, проверка отправки сообщений электронной почты или размещения заказа).

Примеры:

Другие варианты защиты API

Хотя авторизация предпочтительна, и OAuth 2.0 стал доминирующим методом включения строгой авторизации для API, Управление API предоставляет несколько других механизмов для защиты или ограничения доступа между клиентом и шлюзом (стороной клиента) или между шлюзом и серверной частью (стороной службы). В зависимости от требований организации они могут использоваться для дополнения OAuth 2.0. Кроме того, настройте их независимо, если вызывающие приложения или внутренние API являются устаревшими или еще не поддерживают OAuth 2.0.

Параметры на стороне клиента

Механизм Description Рекомендации
Mtls Проверка сертификата, представленного клиентом подключения и свойствами сертификата проверка для сертификата, управляемого в Управление API Сертификат может храниться в хранилище ключей.
Ограничение IP-адресов вызывающих объектов Фильтрация вызовов (разрешить или запрет) из определенных IP-адресов или диапазонов адресов. Используйте для ограничения доступа к определенным пользователям или организациям или трафику из вышестоящий служб.
Ключ подписки Ограничение доступа к одному или нескольким API на основе подписки Управление API Мы рекомендуем использовать ключ подписки (API) в дополнение к другому методу проверки подлинности или авторизации. В собственных случаях ключ подписки не является сильной формой проверки подлинности, но использование ключа подписки может оказаться полезным в определенных сценариях, например отслеживание использования API отдельных клиентов или предоставление доступа к определенным продуктам API.

Совет

Для подробной защиты настоятельно рекомендуется развернуть брандмауэр веб-приложения вышестоящий экземпляра Управление API. Например, используйте Шлюз приложений Azure или Azure Front Door.

Параметры на стороне службы

Механизм Description Рекомендации
Проверка подлинности управляемого удостоверения Проверка подлинности в серверном API с помощью управляемого удостоверения, назначаемого системой или назначаемого пользователем. Рекомендуется для область доступа к защищенному внутреннему ресурсу путем получения маркера из идентификатора Microsoft Entra.
Проверка подлинности сертификата Проверка подлинности в серверном API с помощью сертификата клиента. Сертификат может храниться в хранилище ключей.
Обычная проверка подлинности Проверка подлинности в серверном API с помощью имени пользователя и пароля, передаваемых через заголовок авторизации. Не рекомендуется, если доступны лучшие варианты.

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