Die vielen Gesichter des OAuth 2.0 Token Exchange

• Ein standardbasierter Mechanismus, um ein Sicherheitstoken in ein anderes Token umzuwandeln, definiert in RFC 8693 als Erweiterungsspezifikation für OAuth 2.0
• Wandelt den Authorization Server in einen Security Token Service (STS) um, der vom Client gesendete Tokens validiert und neue Tokens ausstellt, die zu einem anderen Kontext, Ziel (audience) oder Zweck passen
• Die Funktionsweise lässt sich grob in zwei Modi unterteilen: Impersonation und Delegation
• Für unterschiedliche Anwendungsfälle wie administrative Impersonation, Protokollumstellung, Service-Chaining und föderierte Identitäten gibt es jeweils Trade-offs und sicherheitsrelevante Auswirkungen
• Mit der Verbreitung von AI-Agenten werden Aufgaben, die sich über mehrere Services und Anbieter erstrecken, im Kern zu Delegationsketten — dadurch wird Token Exchange noch wichtiger

---

Was ist Token Exchange?

• Der Client sendet ein subject_token (ein Token, das den Benutzer bzw. die Entität repräsentiert, die Gegenstand der Anfrage ist) und optional zusätzlich ein actor_token (die Partei, die den Austausch durchführt), um ein neues Token zu erhalten, das zum Zielkontext passt
• Es wirkt zunächst naheliegend, das bestehende Token einfach weiterzureichen oder ein neues Token direkt neu zu erzeugen, aber beide Ansätze verursachen gravierende Probleme — diese Spezifikation wurde geschaffen, um genau das zu lösen

• Zwei grundlegende Betriebsmodi

  • Impersonation: Die anfragende Partei erhält ein Token, das vom ursprünglichen Subjekt nicht zu unterscheiden ist; nachgelagerte Services können nicht erkennen, ob die Anfrage vom tatsächlichen Benutzer oder von einer imitierenden Partei stammt
  • Delegation: Die Identität beider Beteiligten bleibt erhalten; über den im neuen Token enthaltenen act-(Actor-)Claim kann ein nachgelagerter Service sowohl den Benutzer als auch den Stellvertreter erkennen
  • Impersonation ist mächtig, aber intransparent; Delegation ist eingeschränkter, dafür auditierbar — diese Wahl bestimmt die Sicherheitslage und die Nachverfolgbarkeit

Administrative Impersonation

• Wenn auf einem Kundendashboard fehlerhafte Daten angezeigt werden und ein Support Engineer das Problem diagnostizieren muss, kann es nötig sein, die Oberfläche mit exakt denselben Berechtigungen und demselben Datenzugriff wie der Kunde zu sehen
• Der Administrator tauscht sein eigenes Token gegen ein Token aus, das die Identität des Kunden repräsentiert; das resultierende Token enthält den sub-Claim, die Scopes und die audience des Kunden, sodass die Anwendung die Anfrage so behandelt, als käme sie vom Kunden selbst
• In diesem Fall wird nur ein subject_token (der zu impersonierende Benutzer) verwendet und kein actor_token mitgegeben — denn das Ziel ist vollständige Impersonation

• Problem des verlorenen Audit-Trails

  • Da es sich um echte Impersonation handelt, geht die Audit-Spur darüber verloren, wer die Aktion tatsächlich ausgeführt hat
  • Deshalb muss dies immer mit einem externen Logging-Mechanismus kombiniert werden, der festhält, wer, wann und aus welchem Grund den Austausch gestartet hat — andernfalls entsteht unter dem Vorwand der Fehlerbehebung eine Sicherheitslücke

Verwaltung von Protokollumstellungen

• In Umgebungen mit verbleibenden Legacy-Systemen und älteren Protokollen entsteht beim Wechsel von SAML-Authentifizierung zu OpenID Connect (OIDC) oft das Szenario, dass beide Systeme vorübergehend parallel betrieben werden
• Ein Service, der Benutzer per SAML authentifiziert, tauscht eine SAML-Assertion gegen ein OAuth-2.0-Access-Token aus; der Authorization Server validiert das eingehende SAML-Artefakt und stellt ein standardisiertes Access-Token aus, das nachgelagerte Systeme verstehen

• Der Parameter subject_token_type

  • Er identifiziert das Format des eingehenden Tokens; RFC 8693 definiert mehrere Bezeichner für Tokentypen
    • SAML-2.0-Assertion: urn:ietf:params:oauth:token-type:saml2
    • JWT-Token: urn:ietf:params:oauth:token-type:jwt
  • Dadurch kann der Authorization Server Tokens aus unterschiedlichen Protokollfamilien entgegennehmen und in ein konsistentes Format für moderne Services normalisieren
• Dieses Muster tritt auch bei Unternehmensfusionen und -übernahmen auf, wenn zwei Organisationen mit unterschiedlichen ID-Stacks interoperabel sein müssen, bevor die vollständige Migration abgeschlossen ist: Benutzer authentifizieren sich weiterhin wie bisher, und das System wandelt die Credentials in die Form um, die der konsumierende Service verlangt

Chaining von Service-Aufrufen

• In einer Microservices-Architektur, in der Service A eine Benutzeranfrage verarbeitet, dann im Namen des Benutzers Service B aufruft und Service B wiederum Service C, lautet die zentrale Frage: Welche Credentials soll jeder Service für den nächsten Aufruf verwenden?

• Option 1 — Eigene Service-Credentials verwenden

  • Service A ignoriert den Benutzerkontext und ruft Service B mit seinen eigenen Client-Credentials auf; das eignet sich für Service-zu-Service-Aufrufe ohne Benutzerkontext, etwa Batch-Verarbeitung, Systemzustandsprüfungen oder Datensynchronisierung
  • Sobald ein Benutzerbezug besteht, kann Service B jedoch keine Autorisierung auf Benutzerebene erzwingen — es ist nicht erkennbar, welcher Benutzer die Anfrage ausgelöst hat, also lassen sich keine Zugriffsrechte prüfen; der Sicherheitskontext geht verloren

• Option 2 — Der Service impersoniert den Benutzer

  • Service A reicht das ursprüngliche Benutzertoken direkt an Service B weiter oder tauscht es gegen ein Token aus, das vom Benutzer nicht zu unterscheiden ist; Service B behandelt die Anfrage dann als direkt vom Benutzer gesendet und wendet Autorisierung auf Benutzerebene an
  • Service B kann jedoch nicht unterscheiden, ob es sich um eine direkte Aktion des Benutzers oder um eine stellvertretende Aktion von Service A handelt; wird Service A kompromittiert, kann es alle Aufrufe innerhalb der Benutzerrechte durchführen, und unterschiedliche Vertrauensniveaus für direkte und Proxy-Anfragen lassen sich nicht anwenden — der Benutzerkontext bleibt erhalten, der Servicekontext geht verloren

• Option 3 — Im Namen des Benutzers handeln (Delegation)

  • Service A tauscht das Benutzertoken gegen ein neues Token aus, das sowohl den Benutzer (subject) als auch Service A (actor) identifiziert; der act-Claim im Ergebnis signalisiert: „Anfrage bezüglich Benutzer X, ausgeführt von Service A“
  • Dies ist das Delegationsmodell, das RFC 8693 primär unterstützen soll; Service B kann damit differenzierte Autorisierungsentscheidungen treffen — versucht Service A eine Aktion, die der Benutzer nicht freigegeben hat, schlägt die Anfrage fehl
  • Der act-Claim kann verschachtelt (nestable) sein; wenn Service B Service C aufruft, wird die Delegationskette erweitert und liefert einen vollständigen Audit-Trail
  • Der Trade-off ist Komplexität — an jedem Hop ist ein Token Exchange nötig, was die Latenz erhöht, und jeder Service muss als Client beim Authorization Server registriert sein; in Architekturen, in denen Sicherheit und Auditing wichtig sind, ist dies jedoch die prinzipientreue Wahl

Token Exchange und föderierte Identitäten

• Wenn Services Domänen- und Vertrauensgrenzen überschreiten müssen (zum Beispiel bei einem Service eines Drittanbieters), wird das Chaining-Szenario deutlich komplexer
  • Service A besitzt ein Token, um im Sicherheitsbereich von MyCompany im Namen eines Benutzers auf Service B zuzugreifen
  • Service B muss Service C aufrufen, das im Bereich eines External Provider geschützt ist, und benötigt dafür ein Access-Token
• Ein von MyCompany ausgestelltes Token ist im Bereich des External Provider bedeutungslos — ein von einem Authorization Server ausgestelltes Token wird nicht automatisch von einem anderen akzeptiert; diese Vertrauensgrenzen existieren, um den möglichen Schaden (blast radius) zu begrenzen

• Grenzen der Föderationskonfiguration

  • Der Authorization Server des External Provider muss so konfiguriert sein, dass er Tokens aus der MyCompany-Domäne als gültige subject-Tokens akzeptiert; dafür braucht es vorab etabliertes Vertrauen über Metadatenaustausch, Zertifikatsvalidierung oder direkte Konfiguration sowie ein Mapping von Identitäten zwischen den Domänen
  • Mit jeder zusätzlichen Domäne — etwa bei Enterprise-Integrationen, SaaS-Ökosystemen oder Multi-Cloud — wird die Matrix bilateraler Vertrauensbeziehungen unbeherrschbar

• Cross App Access und Identity Chaining

  • Cross App Access (XAA) soll dieses Skalierungsproblem lösen; es implementiert den Identity Assertion JWT Authorization Grant und führt einen Enterprise-IdP als Vermittler für domänenübergreifenden Austausch ein
  • Dahinter steht die Erkenntnis, dass der IdP die Beziehung sowohl zu den beiden Applikationen als auch zum Benutzer bereits kennt; statt dass jedes Domänenpaar bilaterales Vertrauen aufbauen muss, werden Zugriffsentscheidungen beim IdP zentralisiert

  • Die 4 Parteien im XAA-Flow

    • Requesting App: die Anwendung (oder der AI-Agent) in der MyCompany-Domäne, die auf Ressourcen in einer anderen Domäne zugreifen muss
    • Enterprise IdP: der Identitätsanbieter der MyCompany-Domäne, der Mitarbeiter authentifiziert und domänenübergreifende App-Richtlinien verwaltet
    • Resource App: die Anwendung in der Domäne des External Provider, die die geschützte API besitzt
    • Resource Authorization Server: der Authorization Server, der Access-Tokens für die geschützte API der Resource App ausstellt

  • Der XAA-Ablauf Schritt für Schritt

    • Ein Mitarbeiter meldet sich per SSO bei der Requesting App an und erhält vom IdP ein ID-Token
    • Die Requesting App sendet dieses ID-Token erneut an den IdP und fordert eine domänenübergreifende Identity Assertion an (ID-JAG, ein spezielles JWT mit Scope für Cross-App-Zugriffe)
    • Der IdP prüft die XAA-Richtlinien — also ob der Zugriff auf die Resource App im Namen dieses Benutzers erlaubt ist — und gibt bei Genehmigung ein ID-JAG zurück
    • Die Requesting App legt das ID-JAG beim Authorization Server der Resource App vor
    • Der Authorization Server der Resource App validiert das ID-JAG über OIDC Discovery mit dem öffentlichen Schlüssel des IdP und stellt dann ein Access-Token aus
    • Die Requesting App ruft mit diesem Access-Token die API der Resource App auf
  • Der entscheidende Unterschied zu gewöhnlichem Token Exchange liegt in Schritt 3: Der IdP erzwingt die Richtlinienentscheidung — Administratoren konfigurieren explizit, welche Apps welche Ressourcen erreichen dürfen, was der IT Transparenz und Kontrolle gibt und Benutzern wiederholte Consent-Flows erspart
  • Identity Chaining ist das umfassendere Muster, bei dem Identity Assertions in standardisierter Form von der initialen Authentifizierung bis zu allen nachgelagerten Services weitergereicht werden; XAA ist eine Implementierung auf Basis von OAuth-Primitiven
  • Besonders relevant ist das bei AI-Agenten-Szenarien, in denen eine einzelne Benutzeranfrage Aufrufe an Services mehrerer Drittanbieter auslöst

Token Exchange und Auth0

• Auth0 implementiert Token Exchange über mehrere Mechanismen, die unterschiedliche Punkte des zuvor beschriebenen Spektrums abdecken

• Custom Token Exchange

  • Implementiert RFC 8693 am /oauth/token-Endpoint von Auth0 und gibt Entwicklern vollständige Kontrolle über die Validierungslogik
  • Definiert ein Token Exchange Profile, das eine subject_token_type-URI auf eine Custom Action abbildet; sobald eine Anfrage eingeht, ruft Auth0 den Action-Code auf, um Tokens zu validieren, Autorisierungsregeln durchzusetzen und den Benutzer mit einem Tenant zu verknüpfen
  • Da Auth0 das subject_token als opaken String behandelt, kann praktisch jedes Format akzeptiert werden — etwa JWTs anderer IdPs, Legacy-SAML-Assertions oder proprietäre Tokens aus Partner-APIs; das ist der Mechanismus für Protokollumstellungen und benutzerdefinierte Föderation

• Token Vault

  • Für AI-Agenten-Szenarien, in denen im Namen des Benutzers Drittanbieter-APIs über mehrere Provider hinweg aufgerufen werden, ergänzt es Token Exchange um sichere Speicherung und automatisches Lifecycle-Management
  • Nach der Authentifizierung verbindet der Benutzer Konten wie Google, GitHub, Slack oder Microsoft; Token Vault speichert die Tokens sicher und übernimmt das automatische Refreshing, während der AI-Agent per Token Exchange ein gültiges Access-Token aus dem Vault abruft
  • Das resultierende Token enthält einen act-Claim, der den AI-Agenten identifiziert — so entsteht ein Audit-Trail darüber, welcher Agent im Namen welches Benutzers auf welchen Service zugegriffen hat; das ist essenziell für Enterprise-Compliance, wenn nachvollziehbar sein muss, was eine Automatisierung ausgelöst hat

• On-Behalf-Of (OBO) Token Exchange

  • Implementiert direkt das Delegationsmuster für Service-Chain-Szenarien: Ein Mid-Tier-Service tauscht ein eingehendes Benutzertoken gegen ein neues, auf eine Downstream-API gescoptes Token aus und fügt sich über den act-Claim selbst in die Delegationskette ein
  • Unterstützt bis zu 5 Ebenen verschachtelter Delegationsketten; jedes Token enthält die Claims sub (Erhalt der Benutzeridentität), aud (auf den Zielservice gescoptes Ziel) und verschachteltes act (Dokumentation der beteiligten Service-Kette)

• Cross App Access (XAA)

  • Für föderierte Identitätsszenarien, in denen eine anfragende Applikation eine Ressourcen-API aufrufen muss, die von einem anderen Authorization Server geschützt wird; implementiert dafür die OAuth-Erweiterung Identity Assertion Authorization Grant
  • Auth0 übernimmt dabei die Rolle des Resource Authorization Server: Die Requesting App sendet das Benutzer-ID-Token an einen IdP wie Okta und erhält ein ID-JAG; nur wenn ein Administrator im Admin Console eine Cross-App-Verbindung konfiguriert hat, stellt der IdP diese Assertion aus
  • Legt die Requesting App das ID-JAG bei Auth0 vor, wird es per OIDC Discovery validiert und anschließend ein gescoptes Access-Token ausgestellt, was der IT zentrale Transparenz über domänenübergreifende Datenfreigaben gibt

Den richtigen Ansatz wählen

• Token Exchange ist keine Einzellösung, sondern eine Sammlung von Mustern; welche Variante passt, hängt davon ab, welcher Kontext erhalten bleiben soll und welche Vertrauensgrenzen überschritten werden müssen
  • Administrative Impersonation: wenn bei der Fehlersuche exakt das sichtbar sein muss, was auch der Benutzer sieht
  • Protokollumstellung: wenn während einer Migration eine Brücke zwischen Legacy- und modernen ID-Systemen benötigt wird
  • Delegation: wenn Service-Ketten Benutzerkontext bei vollständiger Auditierbarkeit erfordern
  • Cross App Access / Identity Chaining: wenn sich Delegation über mehrere Sicherheitsdomänen erstreckt
  • Token Vault: wenn AI-Agenten verwalteten Zugriff auf Drittanbieter-APIs im Namen von Benutzern benötigen
• AI-Agenten, die Aufgaben im Namen von Benutzern über mehrere Services und Anbieter hinweg orchestrieren, sind im Kern Delegationsketten; Token-Exchange-Mechanismen bilden die Sicherheitsgrundlage dafür, dass diese Ketten auditierbar, autorisiert und auf die Benutzerintention begrenzt bleiben