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

Подключения OAuth 2.0 в диспетчере учетных данных — сведения о процессах и потоках

  • Статья

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

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

Общие сведения о диспетчере учетных данных в Управление 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. Можно настроить несколько подключений для поставщика.

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

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

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

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

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

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

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