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

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

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

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

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

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

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

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

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

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

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

Поток OAuth

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

• Серверная часть — это устаревший 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 backendам. В этом сценарии пользователь или клиентское приложение выполняет запрос к шлюзу управления API, доступ к которому контролируется с помощью поставщика удостоверений или других вариантов на стороне клиента. Затем с помощью конфигурации политики пользователь или клиентское приложение делегирует серверную проверку подлинности и авторизацию бэкэнду к Управлению API.

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

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

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

Примеры:

• Настройка диспетчера учетных данных — API Microsoft Graph
• Настройка диспетчера учетных данных — API GitHub
• Настройка диспетчера учетных данных — делегированный пользователем доступ к внутренним API

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

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

Опции на стороне клиента

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

Связанный контент

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