Unterstützte Authentifizierungsmuster
AgentCore Identity unterstützt zwei primäre Authentifizierungsmuster, die für unterschiedliche Anwendungsfälle von Agenten geeignet sind. Wenn Sie diese Muster verstehen, können Sie den richtigen Ansatz für Ihre spezifische Agentenimplementierung auswählen.
Ausführliche Beispiele dafür, wie diese Muster auf bestimmte Branchen und Agententypen zutreffen, finden Sie unter Anwendungsbeispiele.
Themen
User-delegated Zugriff (Erteilung des OAuth 2.0-Autorisierungscodes)
Der Ablauf zur Gewährung von OAuth 2.0-Autorisierungscodes ermöglicht es Agenten, mit ausdrücklicher Zustimmung des Benutzers auf benutzerspezifische Daten zuzugreifen. Dieses Muster ist wichtig, wenn Agenten auf persönliche Daten zugreifen oder Aktionen im Namen bestimmter Benutzer ausführen müssen. Der Ablauf umfasst einen Schritt zur Zustimmung des Benutzers, bei dem der Eigentümer der Ressource (Benutzer) den Agenten ausdrücklich autorisiert, innerhalb bestimmter Bereiche auf seine Daten zuzugreifen.
Schlüsselmerkmale
-
Erfordert die ausdrückliche Zustimmung des Benutzers durch eine Autorisierungsaufforderung
-
Ermöglicht den Zugriff auf benutzerspezifische Daten und Ressourcen
-
Sorgt für eine klare Trennung zwischen Agentenidentität und Benutzerautorisierung
-
Unterstützt fein abgestufte Bereiche, die einschränken, auf welche Daten der Agent zugreifen kann
Beispielszenario: Ein Produktivitätsagent muss auf den Google-Kalender eines Nutzers zugreifen, um Besprechungen zu planen, auf Gmail, um E-Mails zu senden, und auf Google Drive, um Dokumente zu speichern. Der Agent verwendet den OAuth 2.0-Autorisierungscode, um die Zustimmung des Benutzers für jeden Dienst einzuholen, wobei bestimmte Bereiche den Zugriff nur auf die erforderlichen Daten beschränken. Der Nutzer autorisiert den Agenten ausdrücklich über den Zustimmungsbildschirm von Google, und AgentCore Identity speichert die resultierenden Anmeldeinformationen sicher für die future Verwendung.
Dieses Muster eignet sich ideal für persönliche Assistenten, Kundendienstmitarbeiter und alle Szenarien, in denen Agenten Zugriff auf benutzerspezifische Daten über mehrere Dienste hinweg benötigen. Detaillierte branchenspezifische Beispiele finden Sie unter Personal Assistant Agents und Customer Service Agents.
Machine-to-machine Authentifizierung (Erteilung von OAuth 2.0-Client-Anmeldeinformationen)
Der Ablauf zur Gewährung von OAuth 2.0-Client-Anmeldeinformationen ermöglicht die direkte Authentifizierung zwischen Systemen ohne Benutzerinteraktion. Dieses Muster eignet sich, wenn Agenten auf Ressourcen zugreifen müssen, die nicht benutzerspezifisch sind, oder wenn Agenten selbst handeln, wenn sie zuvor die Zustimmung des Benutzers eingeholt haben.
Schlüsselmerkmale
-
Keine Benutzerinteraktion oder Zustimmung erforderlich
-
Der Agent authentifiziert sich mit seinen eigenen Anmeldeinformationen direkt bei den Ressourcenservern
-
Geeignet für Hintergrundprozesse, geplante Aufgaben und Operationen auf Systemebene
-
Berechtigungen werden auf Agentenebene und nicht pro Benutzer definiert
Beispielszenario: Ein Datenverarbeitungsagent eines Unternehmens muss Daten aus mehreren internen Systemen sammeln, verarbeiten und die Ergebnisse in einem Data Warehouse speichern. Der Agent verwendet die OAuth 2.0-Client-Anmeldedaten, um sich mit seiner eigenen Identität und vorkonfigurierten Berechtigungen direkt bei jedem System zu authentifizieren. Es ist keine Benutzerinteraktion erforderlich, und der Agent kann arbeiten, wenn die Agenten in festgelegten Intervallen mit vorheriger Zustimmung des Benutzers selbst handeln.
Dieses Muster ist ideal für Automatisierungsagenten, Datenverarbeitungsworkflows und DevOps Automatisierung in Unternehmen. Detaillierte branchenspezifische Beispiele finden Sie unter Agenten für Unternehmensautomatisierung, Datenverarbeitungs- und Analyseagenten und Entwicklung und DevOps Agenten.
On-behalf-of Token-Austausch (OAuth 2.0-Tokenaustausch)
On-behalf-of Der Tokenaustausch (OBO) ermöglicht es Agenten, im Namen eines bereits authentifizierten Benutzers auf nachgelagerte Ressourcenserver zuzugreifen. Der Agent tauscht das eingehende Benutzertoken über einen Anbieter für ausgehende Anmeldeinformationen gegen ein neues, zielgruppenspezifisches Zugriffstoken aus, wodurch sowohl die Identität des Benutzers als auch die Identität des Agenten mit dem resultierenden Token verknüpft werden. Nachgeschaltete Dienste können dann Autorisierungsentscheidungen auf der Grundlage beider Identitäten treffen, ohne dass der Benutzer einen weiteren Zustimmungsfluss durchlaufen muss.
Schlüsselmerkmale
-
Keine zusätzliche Zustimmung des Benutzers — das eingehende Benutzertoken wird direkt gegen ein nachgelagertes Zugriffstoken ausgetauscht
-
Überträgt sowohl die Identität des Benutzers als auch die Identität des Agenten (oder des Workloads) über mehrere Hops hinweg, sodass jeder nachgelagerte Dienst den Kontext hat, in dem er seine eigenen Autorisierungsentscheidungen treffen kann
-
Unterstützt je nach Identitätsanbieter den Standard-Token-Austausch (RFC 8693
) oder die JWT-Autorisierungsgewährung (RFC 7523 )
Beispielszenario: Zugriff auf eine benutzerspezifische Geschäftsanwendung — Ein Unternehmen verfügt über eine interne HR-Anwendung, die eine benutzerspezifische Zugriffskontrolle durchsetzt — jeder Mitarbeiter kann nur seine eigenen Vergütungs- und Leistungsdaten einsehen. Das Unternehmen möchte es Mitarbeitern ermöglichen, diese Anwendung über einen KI-Agenten abzufragen, ohne die bestehenden Zugriffsrichtlinien zu lockern.
-
Mike (Identitätsadministrator) konfiguriert die HR-Anwendung als OAuth-Anmeldeinformationsanbieter in AgentCore Identity, einschließlich des OBO-Token-Austauschmodus. Nach der Einrichtung ist keine benutzerspezifische Bereitstellung erforderlich — jeder Mitarbeiter, der sich beim Agenten authentifizieren kann, kann über ihn auf die HR-Anwendung zugreifen.
-
Bob (Agent-Entwickler) fügt ein Tool hinzu, das die HR-Anwendung aufruft. Er schreibt keine Token-Austauschlogik und kümmert sich auch nicht um Client-Geheimnisse. Er ruft
GetResourceOauth2Tokenmit dem Workload-Zugriffstoken auf, und AgentCore Identity gibt ein Downstream-Token mit Gültigkeitsbereich zurück. Bob konzentriert sich darauf, was der Agent mit den Daten macht, nicht darauf, wie sie autorisiert werden. -
Sarah (Endbenutzerin) meldet sich beim Agenten an und bittet ihn, ihre Leistungsübersicht abzurufen. Sie wird nicht aufgefordert, sich ein zweites Mal anzumelden. Hinter den Kulissen tauscht AgentCore Identity Sarahs eingehendes Token gegen ein nachgeschaltetes Zugriffstoken aus, das ihre Identität enthält. Die HR-Anwendung wendet ihre bestehenden Zugriffsrichtlinien an und gibt nur Sarahs Daten zurück — dieselben Daten, die sie sehen würde, wenn sie direkt auf die Anwendung zugreifen würde.
Dieses Muster ist ideal für Unternehmensagenten, die mehrere identitätsbewusste Dienste in einer einzigen vertrauenswürdigen Domäne nutzen. Ausführliche Informationen zu den Arten von Zuschüssen, der Konfiguration und den unterstützten Identitätsanbietern finden Sie unter Tokenaustausch. On-behalf-of
Auswahl des richtigen Authentifizierungsmusters
Berücksichtigen Sie bei der Entwicklung Ihrer Agentenauthentifizierungsstrategie die folgenden Faktoren, um zu ermitteln, welches Muster am besten geeignet ist:
| Faktor | User-delegated Zugriff (Erteilung des OAuth 2.0-Autorisierungscodes) | Machine-to-machine Authentifizierung (Erteilung von OAuth 2.0-Client-Anmeldeinformationen) | On-behalf-of Token-Austausch (OAuth 2.0-Tokenaustausch) |
|---|---|---|---|
|
Eigentum an Daten |
User-specific Daten (E-Mails, Dokumente, persönliche Kalender) |
System- oder unternehmenseigene Daten (Analysen, Protokolle, gemeinsam genutzte Ressourcen) |
User-specific Daten, bei denen der Benutzer bereits gegenüber dem Agenten authentifiziert ist |
|
Interaktion mit dem Benutzer |
Der Benutzer ist anwesend und kann seine Zustimmung geben |
Keine Benutzerinteraktion erforderlich oder verfügbar |
Der Benutzer ist bereits beim Agenten authentifiziert; keine neue Zustimmungsaufforderung |
|
Zeitpunkt des Vorgangs |
Interaktiver Betrieb in Echtzeit |
Hintergrund-, geplante oder Batch-Operationen |
Interaktive Operationen in Echtzeit, die von einem authentifizierten Benutzer initiiert wurden |
|
Umfang der Genehmigung |
Die Berechtigungen variieren je nach Benutzer und seinen Einwilligungsoptionen |
Konsistente Berechtigungen, die auf Agentenebene definiert sind |
Aus dem Benutzertoken für eingehende Nachrichten und der Richtlinie für nachgelagerte Anbieter abgeleitete Berechtigungen |
Viele Agentenimplementierungen benötigen alle Muster für verschiedene Aspekte ihrer Funktionalität. Ein Kundendienstmitarbeiter könnte beispielsweise vom Benutzer delegierten Zugriff verwenden, um die Daten eines bestimmten Kunden abzurufen, und gleichzeitig die Maschine-zu-Maschine-Authentifizierung verwenden, um auf die Wissensdatenbanken und internen Systeme des Unternehmens zuzugreifen. Derselbe Agent kann auch im Namen des Token-Austauschs die Identität des Benutzers an nachgeschaltete Dienste weitergeben, die die Autorisierung pro Benutzer erzwingen, ohne den Benutzer erneut zu fragen. AgentCore Identity unterstützt alle Muster gleichzeitig, sodass Agenten für jede Ressource, auf die sie zugreifen müssen, den geeignetsten Authentifizierungsmechanismus verwenden können.
Alle Authentifizierungsmuster profitieren von den Kernfunktionen von AgentCore Identity:
-
Sicheres Speichern von Anmeldeinformationen, ohne dass Geheimnisse dem Agentencode preisgegeben werden
-
Konsistente Authentifizierungsschnittstellen für mehrere Ressourcentypen
-
Umfassende Auditprotokollierung für Sicherheit und Compliance
-
Fine-grained Zugriffskontrollen auf der Grundlage von Identität und Kontext
-
Vereinfachte Integration durch das AgentCore SDK
