Zentrale Zugriffssteuerung für dezentrale Identitäten: Mit Token Exchange Identitäten und Automatisierung entkoppeln

Ein Architekturmuster aus zentralen Entscheidungen, verteilter Durchsetzung und konsequentem Zero Trust ermöglicht eine konsistente und verlässliche Authentisierung und Autorisierung. Der Schlüssel ist ein etablierter, oft übersehener Standard: Token Exchange.

Vor zwanzig bis dreißig Jahren war Identity- und Access-Management (IAM) eine überschaubare Disziplin: Es ging um Menschen, die sich an Systemen anmeldeten. Mit der zunehmenden Digitalisierung kamen neue Anforderungen hinzu. Unternehmen mussten beispielsweise auch Mitarbeitern von Partnerunternehmen Zugriff auf bestimmte Bereiche ermöglichen. Dann kamen die Maschinen. REST-APIs etablierten sich, und die Business-to-Business-Kommunikation gewann an Bedeutung.

Heute wächst die Zahl der Identitäten rasant – nicht zuletzt durch künstliche Intelligenz (KI). KI-Agenten greifen immer häufiger auf Daten und Dienste zu. Nach Angaben der Analysten von KuppingerCole übersteigt die Zahl der nicht-menschlichen Identitäten – darunter Dienstkonten, API-Token, Automatisierungspipelines und KI-Agenten – in den meisten Unternehmensumgebungen die Zahl der menschlichen Nutzer inzwischen deutlich, häufig sogar um das 25- bis 50-Fache.

Ob ein Mensch, ein Partner, ein automatisierter Prozess oder ein KI-Agent zugreift, ist heute zweitrangig. Entscheidend ist, ob der Zugriff im jeweiligen Kontext autorisiert werden kann. Gleichzeitig schaffen die wachsende Zahl nicht-menschlicher Identitäten und die Heterogenität der Identity Provider vollkommen neue Rahmenbedingungen.

Zu viel Vertrauen, zu wenig Kontrolle

Anwendungen, Dienste und Identitäten sind heute über Cloud-Plattformen, On-Premises-Umgebungen und Partnernetzwerke verteilt. Um die wachsende Zahl an Identitäten zu verwalten, wählen viele Organisationen den einfachsten Weg: Sie vertrauen externen Identity Providern (IdP). Unternehmensanwendungen akzeptieren deren Identitäten, während der jeweilige IdP den gesamten Lifecycle verwaltet.

Das spart Zeit und Kosten. Gleichzeitig steigt jedoch die Komplexität. Anwendungen müssen nicht nur unterschiedliche Tokenformate verstehen, sondern auch externe Identitäten korrekt auf interne Benutzerkonten abbilden. Ein weiteres Problem ist die wachsende Angriffsfläche. Jeder zusätzliche Identity Provider mit Vertrauensstellung erhöht das Risiko. Wird ein IdP kompromittiert, kann dies Angreifern direkten Zugriff auf Unternehmenssysteme ermöglichen.

Um solche Szenarien zu verhindern, müssen Unternehmen unterschiedliche Identity Provider in ein konsistentes IAM-Konzept integrieren. Das ist anspruchsvoll, denn Tokeninhalte und Vertrauensniveaus unterscheiden sich oft erheblich und erschweren eine einheitliche Autorisierung. Die Lösung liegt in einer klaren Aufgabenteilung und der Entkopplung von Identität und Vertrauensdurchsetzung – ganz im Sinne von Zero Trust: niemals blind vertrauen, jeden Zugriff prüfen und auf das notwendige Minimum beschränken.

Token Exchange: Dolmetscher und Türsteher

Möglich wird dies mit Token Exchange, einem offenen Standard, der in RFC 8693 als Erweiterung von OAuth 2.0 definiert ist. Ein zentraler Dienst prüft zunächst ein eingehendes Token, das die Identität und die zugrunde liegende Vertrauensbeziehung belegt.

Anschließend stellt er ein neues Token aus, das auf das jeweilige Zielsystem und den konkreten Anwendungsfall zugeschnitten ist. Die Architektur übernimmt damit gleich zwei Rollen: Dolmetscher und Türsteher. Als Dolmetscher übersetzt der Dienst ein Token aus einer fremden Anmeldeumgebung – etwa Entra ID – in ein Format, das das Zielsystem versteht. Dabei kann er die enthaltenen Berechtigungen gezielt an den Anwendungsfall anpassen.

Als Türsteher prüft er bei jedem Übergang, ob die Ressource im jeweiligen Kontext genutzt werden darf. Das ausgestellte Token ist entsprechend eingeschränkt und gilt nur für diesen Zugriff. Das funktioniert für einen KI-Agenten ebenso wie für einen menschlichen Nutzer, etwa Mitarbeiter eines Lieferanten oder Partnerunternehmens mit Zugriff auf bestimmte unternehmensinterne Daten.

Auf diese Weise lassen sich unterschiedliche Identity Provider einheitlich behandeln. Die Herkunft einer Identität ist nicht länger entscheidend. Maßgeblich ist, auf welche Ressourcen sie im jeweiligen Kontext zugreifen darf. Diese Entscheidung trifft der Token-Exchange-Server zentral und konsistent – auch beim Einsatz von KI-Agenten, die im Auftrag eines Nutzers handeln.

Ein Beispiel verdeutlicht das Prinzip: Greift ein KI-Agent als Non-Human Identity auf ein Buchhaltungssystem zu, sollten sich seine Berechtigungen an der Rolle des Mitarbeiters orientieren, in dessen Auftrag er handelt – etwa als Sachbearbeiter oder Abteilungsleiter. Der Agent erhält dazu ein Token für die vertretene Person.

RFC 8693 definiert dafür den Actor-Claim („act“), der festhält, dass eine Identität im Auftrag einer anderen handelt. Dadurch bleibt nachvollziehbar, wer einen Auftrag über die KI ausgelöst hat. Das Buchhaltungssystem erkennt die vertretene Person und kann beispielsweise entscheiden, ob eine Zahlung über einen bestimmten Betrag zulässig ist.

Da beide Identitäten protokolliert werden, entsteht ein belastbarer Prüfpfad. Dasselbe Prinzip gilt auch außerhalb von KI-Szenarien, etwa wenn eine Service-Desk-Mitarbeiterin im Auftrag einer Kundin handelt. Anhand des Tokens erkennt das nachgelagerte System, dass der Service Desk die Kundin vertritt.

Ein weiterer Vorteil der Zentralisierung ist die Entlastung der Backend-Services. Sie müssen nur noch einen einheitlichen Tokentyp aus einer vertrauenswürdigen Quelle verarbeiten. Das reduziert die Implementierungskomplexität und vereinfacht den Betrieb, weil eine aufwendige Fehlersuche bei Fehlkonfigurationen entfällt.

Sicherheit durch Segmentierung

Token Exchange spielt seine Stärken auch in segmentierten IT-Landschaften aus. Unternehmen trennen ihre Systeme häufig in Sicherheitszonen, etwa zwischen Frontend und Backend oder zwischen Entwicklungs-, Test- und Produktionsumgebungen.

Mit diesem Standard lässt sich die Trennung nicht nur netzwerktechnisch, sondern auch identitätsbasiert durchsetzen. Ein Frontend-Token wird dann nicht einfach weitergereicht, sondern am zentralen Token-Exchange-Dienst geprüft und gegen ein Token für die Zielzone ausgetauscht. Jeder Durchsetzungspunkt akzeptiert ausschließlich Token, die für seine eigene Sicherheitszone vorgesehen sind.

Der Vorteil zeigt sich im Angriffsfall. Ein entwendetes Token einer Sicherheitszone ist in einer anderen wertlos. Wer beispielsweise einen Frontend-Dienst kompromittiert, erhält dadurch keinen automatischen Zugriff auf das Backend. Solche Grenzen können bei einer Supply-Chain-Attacke entscheidend sein.

Gelangen Angreifer über einen schwächer geschützten Partner ins Unternehmen, verhindert die Segmentierung eine ungehinderte Ausbreitung. Ein Zugriffsmodell auf Basis von Token Exchange unterstützt diese Trennung konsequent und begrenzt so die Auswirkungen eines Angriffs.

Sicherheit, Flexibilität und Wirtschaftlichkeit

Die Zahl der eingesetzten Identity Provider wird in absehbarer Zeit kaum sinken. Gleichzeitig kommt kein Unternehmen am Einsatz von KI und dem Umgang mit Non-Human Identities vorbei. Die Verwaltung von Zugriffsrechten wird dadurch zunehmend komplexer, zumal unterschiedliche Identity Provider und isolierte Silos eine konsistente Autorisierung erschweren.

Genau hier setzt Token Exchange an: Der Standard vereinheitlicht Identitätsquellen und ermöglicht eine zentrale Steuerung von Authentisierung und Autorisierung. Neue Zielsysteme, etwa nach einer Akquisition, lassen sich flexibel anbinden, ohne bestehende Anwendungen anzupassen.

Im Vergleich zur Konsolidierung aller Systeme auf einen einzigen Identity Provider – etwa Entra ID – ist dieser Ansatz meist schneller und kostengünstiger umzusetzen.

Der Umstieg auf ein zentrales Vertrauensmodell muss nicht auf einen Schlag erfolgen. Sinnvoll ist es, mit einem Anwendungsfall zu beginnen, der einen hohen Sicherheitsgewinn oder ein großes Einsparpotenzial verspricht. Weitere Fälle lassen sich anschließend schrittweise integrieren – viele IAM-Lösungen unterstützen Token Exchange bereits über die offenen Standards OAuth 2.0 und OpenID Connect.