Protokoły uwierzytelniania w agentach

Agenci używają protokołów OAuth 2.0 z wyspecjalizowanymi wzorcami wymiany tokenów, które są możliwe dzięki federacyjnym poświadczeniom tożsamości (FIC). Wszystkie przepływy uwierzytelniania agenta obejmują wieloetapowe wymiany tokenów, w których szablon tożsamości agenta podszywa się pod tożsamość agenta w celu wykonywania operacji. W tym artykule opisano protokoły uwierzytelniania i przepływy tokenów używane przez agentów. Obejmuje ona scenariusze delegowania, operacje autonomiczne i wzorce poświadczeń tożsamości federacyjnej. Firma Microsoft zaleca używanie naszych zestawów SDK, takich jak Microsoft Entra SDK dla identyfikatora agenta , ponieważ implementacja tych kroków protokołu nie jest łatwa.

Wszystkie podmioty agenta są poufnymi klientami, które mogą również służyć jako interfejsy API dla scenariuszy On-Behalf-Of. Przepływy interakcyjne nie są obsługiwane dla żadnego typu jednostki agenta, zapewniając, że wszystkie uwierzytelnianie odbywa się za pośrednictwem programowych wymian tokenów, a nie przepływów interakcji użytkownika.

Wymagania wstępne

Jeśli jeszcze nie znasz, zapoznaj się z następującymi dokumentami protokołu.

• Platforma tożsamości firmy Microsoft i OAuth 2.0Behalf-Of flow
• Platforma tożsamości firmy Microsoft i przepływ poświadczeń klienta OAuth 2.0

Obsługiwane typy dotacji

Poniżej przedstawiono obsługiwane typy uprawnień dla aplikacji agenta.

Strategia tożsamości agenta

Szablony tożsamości agenta umożliwiają client_credentials bezpieczne pozyskiwanie tokenu dla scenariuszy personifikacji. jwt-bearer Typ przyznawania ułatwia wymianę tokenów w scenariuszach w imieniu, co umożliwia wzorce delegowania. refresh_token Zezwolenia umożliwiają wykonywanie operacji w tle z kontekstem użytkownika, wspierających długotrwałe procesy, zachowujących autoryzację użytkownika.

Tożsamość agenta

Tożsamości agentów wykorzystują client_credentials do autonomicznych operacji tylko dla aplikacji, umożliwiając niezależną funkcjonalność bez kontekstu użytkownika oraz podszywanie się pod tożsamość agenta użytkownika. Typ uprawnień jwt-bearer obsługuje zarówno przepływ poświadczeń klienta, jak i przepływ On-Behalf Of (OBO), zapewniając elastyczność w stosowaniu wzorców delegowania. refresh_token granty ułatwiają wykonywanie operacji delegowanych przez użytkownika w tle, umożliwiając tożsamościom agentów utrzymanie kontekstu użytkownika w ramach rozszerzonych operacji.

Nieobsługiwane przepływy

Model aplikacji agenta jawnie wyklucza pewne wzorce uwierzytelniania w celu zachowania granic zabezpieczeń. Przepływy OBO korzystające z punktu końcowego /authorize nie są obsługiwane dla żadnej jednostki agenta, co zapewnia, że całe uwierzytelnianie odbywa się programowo.

Funkcje klienta publicznego nie są dostępne, co wymaga, aby wszyscy agenci działali jako klienci poufni. Adresy URL przekierowania nie są obsługiwane.

Wzorce protokołów podstawowych

Agenci mogą działać w trzech trybach podstawowych:

• Agenci działający w imieniu zwykłych użytkowników w usłudze Microsoft Entra ID (agenci interakcyjni). Jest to typowy przepływ "on-behalf-of".
• Agenci, którzy działają we własnym imieniu, używając głównych usług utworzonych dla agentów (autonomiczni).
• Agenci działający na własny rachunek, korzystający z kont użytkowników utworzonych specjalnie dla danego agenta (na przykład mający własną skrzynkę pocztową).

Integracja tożsamości zarządzanych

Tożsamości zarządzane są preferowanym typem poświadczeń. W tej konfiguracji token tożsamości zarządzanej służy jako poświadczenie szablonu tożsamości agenta nadrzędnego, podczas gdy standardowe protokoły MSI mają zastosowanie do pozyskiwania poświadczeń. Ta integracja umożliwia identyfikatorowi agenta uzyskanie pełnych korzyści związanych z zabezpieczeniami i zarządzaniem MSI, w tym automatyczną rotacją poświadczeń i bezpiecznym przechowywaniem.

Protokoły Oauth

Istnieją trzy przepływy agenta OAuth:

• Agent działający w imieniu użytkownika w przepływie zadań: agenci działający w imieniu zwykłych użytkowników (agenci interaktywni).
• Przepływ aplikacji autonomicznych: operacje tylko dla aplikacji umożliwiają tożsamościom agentów działanie autonomiczne bez kontekstu użytkownika.
• Przepływ użytkownika agenta: agenci, którzy działają we własnym imieniu, używając tożsamości użytkowników utworzonych specjalnie dla agentów.