Authentifizierungsprotokolle in Agenten

Agents verwenden OAuth 2.0-Protokolle mit speziellen Tokenaustauschmustern, die von Verbundidentitätsanmeldeinformationen (FIC) aktiviert sind. Alle Agent-Authentifizierungsflüsse umfassen mehrstufige Tokenaustausche, bei denen der Agentidentitäts-Blueprint die Identität des Agents zum Ausführen von Vorgängen imitiert. In diesem Artikel werden die Authentifizierungsprotokolle und Tokenflüsse erläutert, die von Agents verwendet werden. Es behandelt Delegierungsszenarien, autonome Vorgänge und Verbundidentitäts-Anmeldeinformationsmuster. Microsoft empfiehlt, unsere SDKs wie Microsoft Entra ID Auth SDK (Sidecar) zu verwenden, da die Implementierung dieser Protokollschritte nicht einfach ist.

Alle Agententitäten sind vertrauliche Clients, die auch als APIs für On-Behalf-Of-Szenarien dienen können. Interaktive Flüsse werden für keinen Agententitätstyp unterstützt, sodass sichergestellt wird, dass alle Authentifizierungen über programmgesteuerte Tokenaustausche und nicht über Benutzerinteraktionsflüsse erfolgen.

Warnung

Microsoft empfiehlt die Verwendung der genehmigten SDKs wie Microsoft. Identity.Web- und Microsoft Entra ID Auth SDK-Bibliotheken (Sidecar) zum Implementieren dieser Protokolle. Die manuelle Implementierung dieser Protokolle ist komplex und fehleranfällig, und die Verwendung der SDKs trägt dazu bei, Sicherheit und Compliance mit bewährten Methoden sicherzustellen.

Voraussetzungen

Wenn Sie noch nicht vertraut sind, gehen Sie die folgenden Protokolldokumente durch.

• Microsoft Identity Platform und OAuth 2.0 On-Behalf-Of Flow
• < c0 >Microsoft Identity Platform und der OAuth 2.0-Client-Anmeldeinformationenfluss< /c0 >

Unterstützte Grant-Typen

Im Folgenden werden die unterstützten Gewährungstypen für Agentanwendungen aufgeführt.

Agent-Identitätsentwurf

Agentidentitäts-Blaupausen unterstützen client_credentials die Aktivierung des sicheren Tokenerwerbs für Impersonierungs-Szenarien. Der jwt-bearer Grant-Typ erleichtert den Tokenaustausch in On-Behalf-Of-Szenarien, sodass Delegierungsmuster möglich sind. refresh_token Berechtigungen ermöglichen Hintergrundoperationen mit Benutzerkontext und unterstützen langandauernde Prozesse, die die Benutzerautorisierung aufrechterhalten.

Agent-Identität

Agentenidentitäten verwenden client_credentials für rein app-basierte autonome Vorgänge, wodurch unabhängige Funktionen ohne Benutzerkontext ermöglicht werden, sowie die Identitätsübernahme für eine Benutzeragentenidentität. Der jwt-bearer-Erteilungstyp unterstützt sowohl den Client-Anmeldeinformations-Flow als auch den On-Behalf Of (OBO)-Flow, was Flexibilität in Delegierungsmustern bietet. refresh_token-Berechtigungen ermöglichen vom Benutzer delegierte Vorgänge im Hintergrund, wodurch Agentenidentitäten den Benutzerkontext über mehrere Vorgänge hinweg beibehalten können.

Nicht unterstützte Abläufe

• Das Agentanwendungsmodell schließt explizit bestimmte Authentifizierungsmuster aus, um Sicherheitsgrenzen aufrechtzuerhalten. Agents werden für interaktive (/authorize) Abläufe nicht unterstützt, wodurch sichergestellt wird, dass die gesamte Authentifizierung programmgesteuert erfolgt.
• Öffentliche Clientfunktionen sind nicht verfügbar, sodass alle Agents als vertrauliche Clients arbeiten müssen.
• Eine Webumleitungs-URI kann in einem Blueprint nur für Einwilligungsabläufe (response_type=none) konfiguriert werden, kann aber nicht für die interaktive Tokenanforderung verwendet werden. Die vollständige Umleitungs-URI-Funktionalität ist für die Clientanwendung konfiguriert.

Kernprotokollmuster

Agenten können in drei Hauptmodi arbeiten.

• Agents, die im Namen regulärer Benutzer in Microsoft Entra ID (interaktive Agents) tätig sind. Dies ist ein regulärer On-Behalf-Of-Fluss.
• Agenten, die in ihrem eigenen Auftrag tätig sind, verwenden Dienstprinzipale, die für sie (autonom) erstellt wurden.
• Agenten, die in ihrem eigenen Auftrag arbeiten, mithilfe von Benutzerprinzipalen, die speziell für diesen Agenten erstellt wurden (z. B. Agenten mit eigenem Postfach).

Integration verwalteter Identitäten

Verwaltete Identitäten sind der bevorzugte Anmeldedatentyp. In dieser Konfiguration dient das verwaltete Identitätstoken als Anmeldeinformation für die Identitätsvorlage des übergeordneten Agents, während standardmäßige MSI-Protokolle für den Erwerb von Anmeldeinformationen gelten. Diese Integration ermöglicht es der Agent-ID, um die umfassenden Vorteile der MSI-Sicherheit und -Verwaltung zu nutzen, einschließlich der automatischen Rotation von Anmeldeinformationen und der sicheren Speicherung.

Warnung

Geheime Clientschlüssel dürfen in Produktionsumgebungen aufgrund von Sicherheitsrisiken nicht als Clientanmeldeinformationen für Agent-Identitätsblaupausen verwendet werden. Verwenden Sie stattdessen sicherere Authentifizierungsmethoden wie Verbundidentitätsanmeldeinformationen (FIC) mit verwalteten Identitäten oder Clientzertifikaten. Diese Methoden bieten eine verbesserte Sicherheit, da vertrauliche geheime Schlüssel nicht direkt in Ihrer Anwendungskonfiguration gespeichert werden müssen.

Oauth-Protokolle

Es gibt drei Agent-OAuth-Abläufe:

• Agent, der im Auftrag des Workflows handelt: Agents, die im Auftrag regulärer Benutzer (interaktive Agenten) tätig sind.
• Autonomer App-Fluss: Nur-App-Vorgänge ermöglichen es Agentidentitäten, autonom ohne Benutzerkontext zu agieren.
• Ablauf des Benutzerkontos des Agents: Agents, die im eigenen Auftrag ausgeführt werden, mithilfe von Benutzerprinzipalen, die speziell für Agents erstellt wurden.

Verwandte Inhalte

• Grant Agents können auf Microsoft 365 Ressourcen zugreifen – Administratororientierte Anleitungen zur Zustimmung, manuellen Autorisierung und anderen Autorisierungssystemen.
• Ansprüche des Agentidentitätstokens – Anspruchsverweis für Token, die an Agents ausgestellt wurden.