Протоколы проверки подлинности в агентах

Агенты используют протоколы OAuth 2.0 со специализированными шаблонами обмена токенами, обеспеченными федеративными учетными данными удостоверения (FIC). Все потоки аутентификации агента включают многоэтапные обмены токенами, в которых идентификационный план агента имитирует его удостоверение для выполнения операций. В этой статье описываются протоколы проверки подлинности и потоки маркеров, используемые агентами. В нем рассматриваются сценарии делегирования, автономные операции и шаблоны учетных данных федеративного удостоверения. Майкрософт рекомендует использовать такие пакеты SDK, как Microsoft Entra SDK для идентификатора агента так как реализация этих шагов протокола не является простой.

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

Предупреждение

Майкрософт рекомендует использовать утвержденные библиотеки SDK, такие как Майкрософт.Identity.Web и Майкрософт Agent ID SDK, для реализации этих протоколов. Реализация этих протоколов вручную является сложной и подверженной ошибкам, а использование пакетов SDK помогает обеспечить безопасность и соответствие рекомендациям.

Необходимые условия

Если вы еще не знакомы, ознакомьтесь со следующими документами по протоколу.

Поддерживаемые типы грантов

Ниже приведены поддерживаемые типы разрешений для агентских приложений.

Схема идентификации агента

Шаблоны удостоверения агента поддерживают получение безопасных токенов для сценариев имитации. Тип предоставления jwt-bearer упрощает обмен токенами в сценариях от имени, что позволяет использовать шаблоны делегирования. refresh_token предоставляет возможность выполнения фоновых операций с контекстом пользователя, поддерживая длительные процессы, сохраняющие авторизацию пользователей.

Удостоверение агента

Удостоверения агента используются client_credentials только для автономных операций приложений, обеспечивая независимые функциональные возможности без контекста пользователя, и имитация для удостоверения агента пользователя. Тип jwt-bearer предоставления поддерживает клиентский поток учетных данных и поток от имени (On-Behalf Of, OBO), что обеспечивает гибкость в шаблонах делегирования. refresh_token предоставляет возможность выполнять фоновые операции, делегированные пользователем, что позволяет агентам сохранять контекст пользователя в длительных операциях.

Неподдерживаемые потоки

Модель приложения агента явным образом исключает определенные шаблоны проверки подлинности для поддержания границ безопасности. Потоки OBO, использующие конечную точку /authorize , не поддерживаются для любой сущности агента, гарантируя, что все проверки подлинности выполняются программным способом.

Возможности общедоступных клиентов отсутствуют, поэтому все агенты должны работать как доверенные клиенты. URL-адреса перенаправления не поддерживаются.

Основные шаблоны протокола

Агенты могут работать в трех основных режимах:

  • Агенты, работающие от имени обычных пользователей в Microsoft Entra ID (интерактивные агенты). Это обычный поток от имени.
  • Агенты, работающие от собственного имени с помощью субъектов-служб, созданных для агентов (автономных).
  • Агенты, работающие от собственного имени с помощью субъектов-пользователей, созданных специально для этого агента (например, агенты, имеющие собственный почтовый ящик).

Интеграция управляемых удостоверений

Управляемые идентификационные данные — это предпочтительный тип учетных данных. В этой конфигурации управляемый маркер удостоверения служит учетными данными для схемы удостоверений родительского агента, а стандартные протоколы MSI применяются к получению учетных данных. Эта интеграция позволяет идентификатору агента получить все преимущества безопасности и управления MSI, включая автоматическую смену учетных данных и безопасное хранилище.

Предупреждение

Секреты клиента не должны использоваться в качестве учетных данных клиента в рабочих средах для схем удостоверений агента из-за рисков безопасности. Вместо этого используйте более безопасные методы проверки подлинности, такие как учетные данные федеративной идентификации (FIC) с управляемыми идентификациями или клиентские сертификаты. Эти методы обеспечивают повышенную безопасность, устраняя необходимость хранения конфиденциальных секретов непосредственно в конфигурации приложения.

Протоколы Oauth

Существует три механизма OAuth агента.

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

  • Last updated on