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

Подключения OAuth 2.0 в менеджере удостоверений — подробности процессов и потоков

  • Статья

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

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

Общие сведения о менеджере учетных данных в службе управления API см. в разделе Сведения о менеджере учетных данных и учетных данных API вв службе управления API.

Управление подключениями

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

На следующем рисунке представлен процесс создания подключения в службе управления API, использующего тип предоставления кода авторизации.

схема , показывающая поток процесса для создания учетных данных.

Этап Описание
1 Клиент отправляет запрос на создание поставщика учетных данных
2 Создается поставщик учетных данных, а ответ отправляется обратно
3 Клиент отправляет запрос на создание подключения
4 Устанавливается соединение, а ответ отправляется обратно с информацией о том, что соединение неактивно.
5 Клиент отправляет запрос на получение URL-адреса входа для запуска согласия OAuth 2.0 у поставщика учетных данных. Запрос содержит URL-адрес после перенаправления, который будет использоваться на последнем шаге
6 Ответ возвращается с URL-адресом входа, который должен использоваться для запуска потока согласия.
7 Клиент открывает браузер с URL-адресом входа, предоставленным на предыдущем шаге. Браузер перенаправляется на процесс получения согласия OAuth 2.0 поставщика учетных данных
8 После утверждения согласия браузер перенаправляется с кодом авторизации на URL-адрес перенаправления, настроенный в поставщике учетных данных.
9 Управление API использует код авторизации для получения токенов доступа и обновления.
10 Управление API получает маркеры и шифрует их.
11 Управление API осуществляет перенаправление на указанный URL-адрес из шага 5

Поставщик удостоверений

При настройке поставщика учетных данных можно выбрать различных поставщиков OAuth и методы предоставления (код авторизации или учетные данные клиента). Для каждого поставщика требуются определенные конфигурации. Важно учитывать следующее:

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

Примечание.

С помощью поставщика generic OAuth 2.0 другие поставщики удостоверений, поддерживающие стандарты потока OAuth 2.0, можно использовать.

При настройке поставщика учетных данных за кулисами диспетчер учетных данных создает хранилище учетных данных , которое используется для кэширования маркеров доступа и маркеров обновления поставщика OAuth 2.0.

Подключение к поставщику учетных данных

Чтобы получить доступ и использовать токены для поставщика, клиентские приложения должны подключиться к поставщику учетных данных. Данное подключение разрешено политиками доступа , основанными на идентичностях Microsoft Entra ID. Можно настроить несколько подключений для поставщика.

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

Тип предоставления Описание
Код авторизации Привязан к контексту пользователя, то есть пользователю необходимо предоставить согласие на подключение. Если маркер обновления действителен, управление API может получить новые маркеры доступа и обновления. Если маркер обновления становится недействительным, пользователю необходимо повторно выполнить проверку подлинности. Все поставщики учетных данных поддерживают код авторизации. Подробнее
Учетные данные клиента Не привязан к пользователю и часто используется в сценариях взаимодействия между приложениями. Для типа предоставления учетных данных клиента не требуется согласие, и подключение не становится недействительным.  Подробнее

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

Политика доступа

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

Идентичность Описание Преимущества Соображения
Принципал службы Удостоверение, маркеры которого можно использовать для проверки подлинности и предоставления доступа к определенным ресурсам Azure, когда организация использует идентификатор Microsoft Entra. Используя служебный принципал, организации избегают создания вымышленных пользователей для управления аутентификацией, когда им нужно получить доступ к ресурсу. Учетная запись службы — это идентификатор Microsoft Entra, представляющий собой зарегистрированное приложение Microsoft Entra. Позволяет более жестко ограничить доступ к сценариям подключения и делегирования пользователей. Не привязан к конкретному экземпляру службы управления API. Использует Microsoft Entra ID для проверки и применения разрешений. Для получения контекста авторизации требуется токен Microsoft Entra ID.
Управляемое удостоверение <Your API Management instance name> Этот параметр соответствует менеджируемому идентификатору, связанному с управлением API. По умолчанию доступ предоставляется управляемому удостоверению, назначенному системой, для соответствующего экземпляра управления API. Идентификация привязана к экземпляру системы управления API. Любой пользователь с доступом вкладчика к экземпляру API Management может получить доступ к любому подключению, предоставляющему разрешения для управляемого удостоверения.
Пользователи или группы Пользователи или группы в клиенте Идентификатора Microsoft Entra. Позволяет ограничить доступ к определенным пользователям или группам пользователей. Требуется, чтобы у пользователей была учетная запись идентификатора Microsoft Entra.

Время выполнения подключений

Для среды выполнения требуется, чтобы серверный API OAuth 2.0 был настроен с помощью политики get-authorization-context. Во время исполнения политика извлекает и сохраняет токены доступа и обновления из хранилища учетных данных, установленного Управлением API для поставщика. Когда в Управление API поступает вызов и выполняется политика get-authorization-context, сначала проверяется, является ли существующий токен авторизации действительным. Если срок действия маркера авторизации истек, служба управления API использует поток OAuth 2.0 для обновления сохраненных маркеров от поставщика учетных данных. Затем маркер доступа используется для авторизации доступа к серверной службе.

Во время выполнения политики доступ к маркерам также проверяется с помощью политик доступа.

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

схема, показывающая процесс получения токена в режиме выполнения.

Этап Описание
1 Клиент отправляет запрос экземпляру службы "Управление API"
2 Политика get-authorization-context проверяет, действителен ли маркер доступа для текущего подключения.
3 Если срок действия маркера доступа истек, но маркер обновления действителен, управление API пытается получить новые маркеры доступа и обновления из настроенного поставщика учетных данных.
4 Поставщик учетных данных возвращает маркер доступа и маркер обновления, которые шифруются и сохраняются в службе управления API.
5 После получения токенов токен доступа присоединяется с помощью политики set-header в качестве заголовка авторизации к исходящему запросу к серверному API.
6 Ответ возвращается в управление API
7 Ответ возвращается клиенту

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