Wie ID-JAG KI-Agenten bei der Authentifizierung unterstützt

KI-Agenten wechseln von Chatbots zu echten Arbeitsaufgaben. Sie fragen Datenbanken ab, versenden Nachrichten, aktualisieren Tickets und greifen auf ein Dutzend Drittanbieter-Apps zu, um in Ihrem Namen zu handeln. Diese Entwicklung bricht mit dem alten Authentifizierungsmodell.

Bisher bedeutete jedes Tool, das ein Agent verwendet, entweder eine weitere OAuth-Zustimmungsabfrage oder einen weiteren, langlebigen API-Schlüssel in Ihren Systemen. ID-JAG löst dieses Problem. Ihr Identitätsanbieter kann Agenten damit bereichsbezogene, kurzlebige Token für die APIs anderer Apps bereitstellen – ohne dass für jede App eine separate Zustimmungsabfrage erforderlich ist.

Dieser Artikel erklärt, was ID-JAG ist, wie der Authentifizierungsablauf Schritt für Schritt funktioniert, wo es sich neben Cross-App Access einfügt und welche Einschränkungen man vor der Einführung kennen sollte.

Was ist ID-JAG?

ID-JAG steht für Identity Assertion JWT Authorization Grant. Es ermöglicht Ihrem Identitätsanbieter (IdP), beispielsweise miniOrange, einem KI-Agenten ein zeitlich begrenztes Token mit begrenztem Gültigkeitsbereich für die API einer anderen Anwendung, etwa Salesforce, zu erteilen. Dies geschieht, ohne dass jeder Benutzer eine Zustimmungsabfrage durchlaufen muss oder dem Agenten ein dauerhafter Schlüssel übergeben wird.

Entscheidend ist, dass ID-JAG kein neues Protokoll erfindet. Es verknüpft zwei bereits existierende OAuth-Standards. Mithilfe des OAuth-Token-Austauschs erhält es die ID-JAG von Ihrem Identitätsanbieter (IdP) und anschließend den JWT-Bearer-Grant, um diese gegen ein echtes Zugriffstoken der Zielanwendung einzutauschen. Die ID-JAG selbst ist ein signiertes JWT, das im Prinzip Folgendes bestätigt: Dieser Agent darf im Namen dieses Benutzers mit diesen Berechtigungen ein Token für diese API abrufen.

Für die Authentifizierung von KI-Agenten stellt dies eine bedeutende Änderung dar. Die Autorisierung wird von einer benutzer- und anwendungsbezogenen Entscheidung auf eine zentrale Richtlinie umgestellt. ID-JAG erweitert das Vertrauensmodell von Single Sign-On auf den API-Zugriff. Derselbe Identitätsanbieter (IdP), dem Ihre Anwendungen bereits für SSO vertrauen, vermittelt nun den API-Zugriff zwischen ihnen. Ursprünglich 2024 als IETF-Entwurf veröffentlicht, ging ID-JAG Mitte 2026 in Produktion, als MCP die darauf aufbauende unternehmensweite Autorisierung einführte.

Warum KI-Agenten ein neues Authentifizierungsmodell benötigen

Das alte Modell ist für Agenten nicht skalierbar. Nehmen wir einen einzelnen KI-Assistenten, der unternehmensweit eingesetzt wird. Tausend Mitarbeiter, die einen solchen Assistenten nutzen, der auf Salesforce zugreift, müssen tausendmal die Zustimmungsmaske von Salesforce durchlaufen – einmal pro Person. Schlimmer noch: Jede Zustimmung stellt eine private Beziehung zwischen dem jeweiligen Mitarbeiter und Salesforce dar, sodass das Unternehmen keine zentrale Stelle hat, um diese einzusehen oder zu deaktivieren.

Dies führt zu drei konkreten Problemen:

• Einwilligungsmüdigkeit: Im Kontext von KI-Agenten bedeuten mehr Tools in der Regel auch mehr Zustimmungs-Popups. Nutzer klicken reflexartig auf „Zulassen“, was das Gegenteil einer informierten Autorisierung ist.
• Schatten-KI: Mitarbeiter verbinden nicht genehmigte KI-Tools ohne jegliche Aufsicht mit Unternehmensdaten. Dieses Problem der Schatten-KI, bei dem interne Nutzer nicht genehmigte Tools zur Verarbeitung von Unternehmensdaten einsetzen, birgt ein hohes Risiko für Datenlecks.
• Kein zentraler Widerruf: Da Berechtigungen zwischen einzelnen Benutzern und einzelnen Apps gelten, gibt es keine Möglichkeit, den Zugriff für alle gleichzeitig zu widerrufen.

Unternehmen kontrollieren bereits, welche Apps Mitarbeiter nutzen dürfen. Sie wollen dieselbe Kontrolle und Transparenz über die API-Integrationen, auf die ihre Agenten angewiesen sind, und die Übertragung der Entscheidung an den Identitätsanbieter (IdP) ist der Weg dorthin.

So funktioniert ID-JAG: Der Authentifizierungsablauf

Die ID-JAG-Architektur basiert auf einer einfachen Umstrukturierung. Der Agent fordert niemals eine Genehmigung vom Benutzer an. Er fragt den Identitätsanbieter (IdP), der bereits weiß, welche Ressourcen jeder Mitarbeiter nutzen darf. Vier Rollen sind beteiligt: ​​der anfragende Agent, der unternehmensweite IdP, der Autorisierungsserver der Zielanwendung und der Ressourcenserver (die eigentliche API). Der Ablauf besteht aus fünf Schritten.

Benutzer meldet sich per SSO an

Der Benutzer meldet sich über sein gewohntes SSO beim Agenten an, und der Identitätsanbieter (IdP) stellt ein ID-Token aus. Dies entspricht dem Standard von OpenID Connect, dem gleichen SSO-Anmeldeverfahren, das Ihre Anwendungen bereits verwenden. Das ID-Token bildet die Vertrauensbasis, auf der alle nachfolgenden Prozesse aufbauen. Vom Benutzer werden an dieser Stelle keine weiteren Angaben verlangt.

Die Identität wird an den KI-Agenten delegiert.

Die Webanwendung übergibt dieses ID-Token an den Agenten, damit dieser im Namen des Nutzers handeln kann. Hier findet die Identitätsdelegierung statt. Die beim Anmelden einmalig verifizierte Identität des Nutzers steht dem Agenten nun zur Verfügung. Wichtig ist, dass der Agent sich nicht als Nutzer ausgibt. Das Token, das er schließlich erhält, enthält sowohl den Namen des Nutzers als auch den des in seinem Namen handelnden Agenten.

Token-Austausch zwischen Diensten

Der Agent sendet das ID-Token an den Identitätsanbieter (IdP) zurück und fordert Zugriff auf eine bestimmte Anwendung an. Dies ist ein OAuth-Token-Austausch, und der IdP prüft die Richtlinien der Organisation, bevor er antwortet: Darf diese Person über diesen Agenten Salesforce erreichen? Bei Genehmigung sendet der IdP die ID-JAG zurück. Die Anfrage sieht folgendermaßen aus:

POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
subject_token=<the user's ID token>
audience=https://salesforce.example.com
scope=chat.read chat.history

Der Agent tauscht die ID-JAG anschließend mit der Ziel-App mittels JWT-Bearer-Grant (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer) aus. Ein wichtiger Punkt aus dem Entwurf: Der Identitätsanbieter (IdP) darf keine Zugriffstoken als Antwort auf eine von ihm selbst ausgestellte ID-JAG ausstellen, da dies den Autorisierungsbereich unbeabsichtigt erweitern könnte. Die beiden Autorisierungsserver bleiben bewusst getrennt.

KI-Agent greift auf geschützte Ressourcen zu

Der Autorisierungsserver der Ziel-App bestätigt, dass ein vertrauenswürdiger Identitätsanbieter (IdP) die ID-JAG signiert hat, und gibt anschließend ein gültiges Zugriffstoken zurück. Dies ist ein standardmäßiges OAuth-Bearer-Token, das in der Regel etwa eine Stunde gültig ist. Der Agent verwendet es, um die API aufzurufen und die angeforderten Aufgaben auszuführen.

Hier liegt das Detail, das Unternehmen die Kontrolle ermöglicht: Läuft das Zugriffstoken ab, fordert der Agent ein neues vom Identitätsanbieter (IdP) an, anstatt ein eigenes Aktualisierungstoken zu verwalten. Diese Designentscheidung erlaubt es Unternehmen, den Agentenzugriff zentral zu steuern und zu entziehen. Der IdP führt bei jeder Verlängerung eine erneute Richtlinienprüfung durch, sodass der Entzug des Zugriffs so einfach ist wie eine Richtlinienänderung. Die Suche nach verstreuten Anmeldeinformationen in unzähligen Anwendungen entfällt.

Der ID-JAG enthält umfassende Kontextinformationen: den Benutzer (sub), den Agenten (client_id), den Zielautorisierungsserver (aud), die gewährten Berechtigungen (scp) und den ausstellenden Identitätsanbieter (IdP). Dadurch kann das Token protokollieren, in wessen Auftrag, von welchem ​​Agenten und in welchem ​​Umfang auf eine Ressource zugegriffen wurde. Da der IdP beim Token-Austausch eine zentrale Richtlinienauswertung durchführt, werden die von der KI oder externen Anwendung angeforderten Berechtigungen von den tatsächlich von der Organisation zugelassenen Berechtigungen getrennt. Dies dient als Sicherheitsnetz, das zu weit gefasste Anfragen durch die im Rahmen Ihrer Sicherheitsstandards zulässigen Berechtigungen ersetzt.

ID-JAG und Cross-App Access (XAA)

ID-JAG wird häufig im Zusammenhang mit Cross-App Access (XAA) erwähnt, und es ist wichtig, die Beziehung genau zu verstehen. XAA ist Oktas Implementierung und Markenname des ID-JAG-Standards. Im Okta-Modell wird die Verbindung zwischen Autorisierungsserver und Ressource durch Cross-App Access unterstützt, welches ID-JAG nutzt.

Vereinfacht gesagt ist ID-JAG der offene Standard, d. h. der Autorisierungstyp und das signierte Token. XAA ist ein Produkt eines Anbieters, das darauf aufbaut. Da ID-JAG ein standardisierter OAuth-Grant ist, kann ihn jeder Identitätsanbieter (IdP) und jede Anwendung übernehmen, und andere Identitätsanbieter können dieselbe Spezifikation unter ihrem eigenen Namen implementieren. Die Open-Source-Plattform Athenz der LY Corporation unterstützt beispielsweise ID-JAG unabhängig von Okta.

ID-JAG vs. traditionelles OAuth

Ein weit verbreiteter Irrtum ist, dass ID-JAG OAuth ersetzt. Das stimmt nicht. Die Gegenüberstellung von ID-JAG und OAuth ist irreführend, da ID-JAG eine OAuth-Erweiterung und kein Konkurrent ist. Es nutzt den Token-Austausch (RFC 8693) und den JWT-Bearer-Grant (RFC 7523) und baut auf dem OAuth-Protokoll auf, das Ihre Anwendungen bereits für Single Sign-On (SSO) verwenden.

Alle Funktionen von OAuth bleiben erhalten. ID-JAG verlagert die Autorisierungsentscheidung lediglich von Tausenden einzelner Benutzer auf eine einzige administrative Richtlinie, was die Funktionalität für Agenten im großen Maßstab ermöglicht.

Vorteile von ID-JAG für KI-Agenten

Neben der reibungsloseren Benutzererfahrung bietet ID-JAG konkrete Vorteile für die Sicherheit und den Betrieb von KI-Agenten.

Ein klarer Prüfpfad

Da jede Transaktion über den Identitätsanbieter (IdP) läuft, werden die Verbindungsdaten zentral zusammengeführt. Der IdP kann Tokens ausgeben, die den notwendigen Kontext sowohl zum menschlichen Nutzer als auch zum KI-Agenten enthalten und so eine lückenlose Nachverfolgbarkeit über alle Systeme hinweg gewährleisten. Dies ist von unschätzbarem Wert, um nach einem Vorfall die Verantwortlichkeit zu klären oder die Einhaltung von Vorschriften nachzuweisen.

Zentralisierte Kontrolle über Schatten-KI

Der IdP ist in der Lage, nicht genehmigte Tools abzufangen und zu bewerten, wodurch bisher undurchsichtige externe KI-Verbindungen in standardisierte, überschaubare Prozesse überführt werden.

Weniger Token-Ausbreitung

Der wohl größte operative Vorteil: Die Spezifikation empfiehlt, dass Ressourcenserver keine separaten Aktualisierungstoken ausgeben. Stattdessen senden Clients eine ID-JAG erneut, um ihr Zugriffstoken zu aktualisieren. Dadurch werden langlebige, systemübergreifende Anmeldeinformationen durch protokollbasiertes, dynamisches Vertrauen ersetzt. API-Schlüssel und Aktualisierungstoken, die sich an unzähligen Stellen ansammeln, gehören damit der Vergangenheit an.

Die Akzeptanz spiegelt die Attraktivität wider. Die MCP-Einführung erfolgte mit Okta als erstem IdP, Claude und VS Code als Clients und Anwendungen wie Asana, Atlassian, Canva, Figma, Linear und Supabase im Hintergrund.

Einschränkungen und betriebliche Überlegungen

ID-JAG ist neu, und Ehrlichkeit bezüglich seiner Schwächen ist wichtig. Die Einschränkungen von ID-JAG, die vor der Einführung berücksichtigt werden sollten, lassen sich in einige wenige Kategorien einteilen.

Es ist noch ein Entwurf.

ID-JAG ist weiterhin ein IETF-Internet-Draft und kein finalisierter RFC. Seine Funktionsweise kann sich noch ändern, daher birgt die enge Kopplung der Kernarchitektur an die heutige Spezifikation ein gewisses Risiko.

Jede App muss es unterstützen, und die meisten tun es noch nicht.

Es reicht nicht aus, dass Ihr IdP ID-JAG unterstützt. Jede Zielanwendung bzw. jeder MCP-Server muss dies ebenfalls unterstützen. Die Liste der unterstützten Anwendungen ist derzeit noch kurz.

Es funktioniert nur über OAuth.

Anbieter, die API-Schlüssel, einfache JWTs oder eigene Schemata verwenden, können nur teilnehmen, wenn sie auf OAuth umstellen. Dies schließt APIs aus, die ausschließlich auf Schlüsseln basieren, wie beispielsweise Stripe-Plattformoperationen und die meisten Analysetools.

Es regelt, wer handeln kann, nicht was sie tun.

Das Token besagt, dass der Agent als dieser Benutzer auf eine App zugreifen darf, es regelt jedoch nicht, was der Agent mit diesem Zugriff macht, und schützt auch nicht vor sofortiger Manipulation.

Es gibt auch operative Feinheiten. Da ein ID-JAG ein JWT ist, lässt er sich nach Ausstellung und Weitergabe nur schwer sofort ungültig machen. Kurze Gültigkeitszeiträume mit häufigen Verlängerungen sind der praktikable Weg zu einer effektiven Widerrufung.

Der Identitätsanbieter (IdP) kann bei einem Datenaustausch auch eine zusätzliche Authentifizierung verlangen und den Fehler „inficient_user_authentication“ zurückgeben, wenn der Authentifizierungskontext des Subjekts nicht den Richtlinien entspricht. Ihr System benötigt Logik zur Verarbeitung von erneuten Authentifizierungsaufforderungen. Abschließend sei darauf hingewiesen, dass ID-JAG für vertrauliche Clients empfohlen wird. Öffentliche Clients wie eigenständige mobile Apps sollten weiterhin die interaktive Autorisierungscode-Gewährung verwenden.

Fazit

ID-JAG ist ein echter Fortschritt für die Authentifizierung von KI-Agenten. Indem die Autorisierungsentscheidung von Tausenden einzelner Zustimmungsabfragen auf eine einzige IdP-Richtlinie verlagert wird, werden Zustimmungsmüdigkeit, Schatten-KI und die unkontrollierte Ausbreitung von Token mit einem einzigen architektonischen Schritt bekämpft.

Gleichzeitig bietet es Unternehmen die benötigte Nachverfolgbarkeit und zentrale Zugriffssperrung. Es ist keine Zauberei. Es handelt sich noch um einen IETF-Entwurf; es funktioniert nur über OAuth, und die App-Unterstützung befindet sich in einem frühen Stadium. Doch für die bereits in Ihrem Identitätsanbieter integrierten Apps macht ID-JAG den Agentenzugriff von einem unübersichtlichen Dickicht zu etwas, das Sie zentral einsehen, steuern und deaktivieren können. Genau das ist die Grundlage, die das Agentenzeitalter braucht.

Häufig gestellte Fragen

Ersetzt ID-JAG OAuth?

Nein. ID-JAG ist eine OAuth-Erweiterung, kein Ersatz. Es nutzt den Token-Austausch und den JWT-Bearer-Grant weiter und baut auf dem bereits in Ihren Apps vorhandenen OAuth-System auf. Es entfernt lediglich die Zustimmungsabfrage pro App für Apps, die denselben Identitätsanbieter (IdP) verwenden.

Worin besteht der Unterschied zwischen ID-JAG und XAA?

ID-JAG ist der offene Standard, der den Berechtigungstyp und das signierte Token definiert. Cross-App Access (XAA) ist Oktas Implementierung und Markenname dafür. Andere Identitätsanbieter können ID-JAG implementieren und es unter einem völlig anderen Namen verwenden.

Ist ID-JAG nur für MCP?

Nein. ID-JAG ist ein allgemeiner OAuth-Grant. Die unternehmensverwaltete Autorisierung von MCP ist das erste bekannte System, das darauf aufbaut, aber jeder OAuth-Client und jede Anwendung kann denselben Ablauf implementieren.

Macht ID-JAG meinen KI-Agenten sicherer?

Nicht für sich allein. ID-JAG steuert, wer handeln darf und auf welche Anwendungen zugegriffen werden kann. Es regelt nicht, was der Agent mit diesem Zugriff macht oder schützt vor sofortiger Einschleusung. Es ist eine Ebene in einem umfassenderen Sicherheitskonzept.

Worin unterscheidet sich ID-JAG von der Workload-Identitätsföderation?

Sie sichern unterschiedliche Teile des Pfads und des Stacks eines Agenten, anstatt miteinander in Konkurrenz zu treten. ID-JAG regelt die Delegierung von Anfragen durch einen Benutzer an einen Agenten, der die API einer anderen Anwendung aufruft. Die Workload-Identitätsföderation ermöglicht es Workloads, kurzlebige Anmeldeinformationen anstelle eines statischen Schlüssels zu erhalten.