AWS führt verwalteten Consent Portal für Bedrock AgentCore Identity ein

AWS führt verwalteten Consent Portal für Bedrock AgentCore Identity ein

Amazon Web Services (AWS) hat für Amazon Bedrock AgentCore Identity einen verwalteten Consent Portal eingeführt. Die Einführung wurde im September 2026 bekannt gegeben. Der Portal vereinfacht den OAuth-2.0-Authorization-Code-Flow, mit dem KI-Agenten im Auftrag von Nutzern auf Drittanbieterdienste wie GitHub oder Slack zugreifen. Bisher mussten Kunden, die diesen Drei-Wege-OAuth-Flow nutzten, eine eigene Session-Binding-Infrastruktur aufbauen und betreiben. Konkret umfasste das mehrere Schritte: Sie mussten die Authorization-URL präsentieren, also den Benutzer zum Identity Provider weiterleiten, um die Zustimmung einzuholen. Sie mussten einen öffentlichen HTTPS-Callback hosten, um den Authorization Code nach der Zustimmung entgegenzunehmen. Sie mussten den zurückkehrenden Benutzer authentifizieren, um sicherzustellen, dass der Code dem richtigen Benutzer zugeordnet wird. Sie mussten Browser-Sessions verwalten, um den Zustand über mehrere HTTP-Requests hinweg zu halten. Und schließlich mussten sie CompleteResourceTokenAuth aufrufen, um den Authorization Code gegen OAuth-Tokens einzutauschen. Session-Binding ist erforderlich, um die OAuth-Zustimmung sicher dem jeweiligen Benutzer zuzuordnen, damit der Agent nur auf dessen Daten zugreift.

Diese Schritte übernimmt nun der gehostete Portal vollständig: Er präsentiert die Authorization-URL, hostet den HTTPS-Callback, authentifiziert den Benutzer gegen den OpenID-Connect-Identity-Provider des Unternehmens, verwaltet die Browser-Session und ruft CompleteResourceTokenAuth auf. Dadurch entfällt für Entwickler die Notwendigkeit, eine eigene Callback-Infrastruktur zu betreiben, abzusichern und zu warten. Die resultierenden OAuth-Tokens speichert AgentCore Identity in einem Token Vault. Der Portal hält den OAuth-Flow vollständig server-seitig; der Browser des Benutzers erhält zu keinem Zeitpunkt ein Token. Das bedeutet, dass sensible OAuth-Tokens niemals im Browser gespeichert oder von dort abgefangen werden können. Dadurch reduziert sich das Risiko von Token-Diebstahl durch Cross-Site-Scripting (XSS) oder andere clientseitige Angriffe erheblich. Die Sicherheitsvorteile liegen darin, dass die Tokens ausschließlich in der geschützten AWS-Infrastruktur verbleiben und nicht über unsichere Client-Umgebungen exponiert werden.

Voraussetzungen und Konfiguration des Consent Portals

Für die Nutzung des Consent Portals sind mehrere Komponenten erforderlich. Zunächst muss ein Amazon Bedrock AgentCore Gateway vorhanden sein, das mit JWT-Inbound-Authentication als Quelle konfiguriert ist. Dieses Gateway prüft die eingehenden JWT-Tokens und stellt damit die Vertrauensstellung zum Identity Provider her – es stellt sicher, dass nur authentifizierte Benutzer auf den Portal zugreifen können. Außerdem wird ein Identity Provider benötigt, dessen erlaubte Scopes den Wert 'openid' enthalten. Der 'openid'-Scope stellt die Grundidentität des Benutzers bereit, die für das Consent-Portal erforderlich ist, um den Benutzer eindeutig zu identifizieren und seine Zustimmung korrekt zuzuordnen.

Um eine Verbindung auf der Connections-Seite des Portals erscheinen zu lassen, müssen ein Outbound-OAuth2-Credential-Provider und ein Gateway-Target konfiguriert werden. Der Outbound-Provider repräsentiert die nachgelagerte Ressource, auf die der Agent zugreifen soll, und ist getrennt vom primären IdP. Die Connections-Seite listet genau die Ressourcen auf, für die ein Endbenutzer dem Agenten Zugriff gewähren kann; diese Liste wird durch die an das Gateway angehängten Targets bestimmt. Unterstützte Outbound-Vendoren sind unter anderem GitHub, Slack, Salesforce, Atlassian und LinkedIn. Diese können auch als reine OAuth2-Vendoren dienen, die nicht als primärer IdP fungieren können.

Die Konfiguration erfolgt in mehreren Schritten: Zuerst muss der Consent Portal erstellt werden (create-Operation). Er muss den Status ACTIVE haben und eine portalUrl besitzen, bevor man den Target hinzufügt, weil die Return-URL des Targets von der portalUrl des Portals abhängt. Anschließend erstellt man den Outbound-OAuth2-Credential-Provider für die nachgelagerte Ressource; die CreateOauth2CredentialProvider-Response enthält eine callbackUrl, die einzigartig für den Portal ist. Danach fügt man das Gateway-Target hinzu. Verwaltet werden Consent Portals über die Operationen create, get, list, update und delete. Entwickler können damit Portale anlegen, abrufen, auflisten, aktualisieren und löschen.

Nutzen für Entwickler und Endbenutzer

Der verwaltete Consent Portal bringt praktischen Nutzen für Entwickler und Endbenutzer. Für Entwickler eliminiert die Funktion die Notwendigkeit, benutzerdefinierte OAuth-Callback-Infrastruktur aufzubauen und zu warten. Statt eigene HTTPS-Endpunkte zu hosten, den Authorization Code zu verarbeiten und Session-Binding zu implementieren, können sie einfach den Portal-Link an ihre Nutzer weitergeben. Plattform-Administratoren können die Portal-URL vor Sessions teilen, damit Benutzer vorab Consent geben können. Endbenutzer erhalten eine Self-Service-Oberfläche, über die sie ihren Verbindungsstatus jederzeit selbst prüfen können, ohne einen Administrator kontaktieren zu müssen.

Besonders nützlich ist der Portal für Agenten, die über IDE-basierte Clients oder Model Context Protocol (MCP)-Clients genutzt werden. Diese Clients besitzen in der Regel keine vollständige Browser-Umgebung, um Webseiten darzustellen, Redirects zu verfolgen und Cookies zu verwalten. Dadurch können sie OAuth-Consent-URLs nicht nativ anzeigen und das Post-Consent-Session-Binding nicht durchführen. Der Consent Portal löst dieses Problem, indem er eine gehostete Web-Oberfläche bereitstellt, die den gesamten Consent-Prozess in einem normalen Browser abwickelt und das Session-Binding serverseitig übernimmt. Der Benutzer muss lediglich die Portal-URL aufrufen, sich authentifizieren und zustimmen; der Agent erhält danach die notwendigen Tokens, ohne dass der Client selbst OAuth-Mechaniken implementieren muss. Die Funktion ist in allen kommerziellen AWS-Regionen verfügbar, in denen Amazon Bedrock AgentCore Identity angeboten wird.