Verständnis des Tokenaustauschs in OAuth/OIDC

Eingeführt in RFC 8693, ist der Tokenaustausch eine OAuth-Erweiterung, die es vertrauenswürdigen Clients ermöglicht, einen vorhandenen Token gegen einen neuen mit unterschiedlichen Attributen oder Bereichen auszutauschen. Dieser Mechanismus ist insbesondere nützlich, um einem Dienst, einer Anwendung oder einem Endbenutzer zu ermöglichen, einen normalen OAuth-Zugriffstoken über einen vorautoriserten Token zu erhalten, ohne den vollständigen OAuth-Fluss durchlaufen zu müssen.

Vergleich mit Autorisierungscode-Fluss#

Zuerst werfen wir einen Blick auf den OAuth-Autorisierungscode-Fluss, der der gebräuchlichste Fluss zum Erhalt eines Zugriffstokens ist.

Und dies ist der Tokenaustausch-Fluss:

Umleitung#

Der Hauptunterschied besteht darin, dass im Autorisierungscode-Fluss die Clientanwendung den Benutzer zum Autorisierungsserver umleitet, um ein Zugriffstoken zu erhalten. Im Tokenaustausch kann die Clientanwendung ein Token mit dem Autorisierungsserver austauschen, ohne den Benutzer zur Umleitung einzubeziehen.

Das liegt daran, dass im Autorisierungscode-Fluss die Clientanwendung nicht "vertrauenswürdig" ist und die Anmeldedaten des Benutzers kennen muss, um ein Zugriffstoken zu erhalten. Im Tokenaustausch wird der Clientanwendung vertraut, den Token bereits vom Benutzer erhalten zu haben, und der Autorisierungsserver wird den Token überprüfen und einen neuen ausstellen.

Tokenaussteller und Tokenaustauschdienst#

Im Tokenaustausch-Fluss sind der "Auth Server" nun zwei Teilnehmer:

1. Tokenaussteller: stellt das Subjekttoken an die Clientanwendung aus.
2. Tokenaustauschdienst: validiert das Subjekttoken und stellt ein neues Token an die Clientanwendung aus.

Der Tokenaustauschdienst ist derselbe wie der "Auth Server" im Autorisierungscode-Fluss, und der Tokenaussteller kann ein Drittanbieter-Identitätsanbieter sein oder vom "Auth Server" als dedizierter Dienst abgespalten werden.

Wann sollte man den Tokenaustausch verwenden?#

Der Tokenaustausch-Fluss kann ohne Benutzerinteraktion durchgeführt werden, was in den folgenden Szenarien nützlich ist:

• Personifizierung: Ermöglicht Diensten (z. B. Backend-Mikrodiensten) oder Admin-Benutzern, Aktionen im Namen eines Benutzers durchzuführen, ohne vollständige Benutzeranmeldedaten offenzulegen.
• Automatisierung: Ermöglicht vertrauenswürdigen Diensten, Aktionen automatisch ohne manuelles Eingreifen oder automatisierte Tests durchzuführen.
• Integration mit anderen IdPs: Übersetzt Tokens über unterschiedliche Identitätssysteme hinweg, um ein nahtloses Benutzererlebnis aufrechtzuerhalten und Berechtigungen effektiv zu verwalten. Ein häufiges Szenario ist die Übersetzung eines SSO-Tokens in ein Token für einen nachgelagerten Dienst.
• Migration: Migriert Tokens von einem Autorisierungsserver zu einem anderen, z. B. von einem veralteten System zu einem modernen OAuth/OIDC-konformen System.

Tokenaustausch-Prozess#

Der Austausch für ein neues Zugriffstoken ist der häufigste Anwendungsfall, den wir als Beispiel nehmen. Nicht nur auf Zugriffstoken beschränkt, kann der Tokenaustausch auch für die Ausstellung anderer Tokentypen wie Auffrischungstoken, ID-Token usw. verwendet werden.

Clientanwendung#

Um den Tokenaustausch durchzuführen, ist eine registrierte Clientanwendung beim Autorisierungsserver erforderlich.

Und die Clientanwendung muss ein subject_token haben, bevor der Tokenaustausch-Fluss eingeleitet wird. Dieses Token wird in der Regel vom Autorisierungsserver oder dem vertrauenswürdigen dritten Identitätsanbieter gewährt. Durch das Vorhandensein dieses Tokens kann die Clientanwendung nun "vertrauenswürdig" sein, um Tokens auszutauschen, ohne die Anmeldedaten und die Interaktion des Benutzers zu benötigen.

Tokenaustauschanfrage#

Der Client sendet eine Anfrage an den Token-Endpunkt des Autorisierungsservers, um ein bestehendes Token auszutauschen. Dies umfasst das subject_token (das auszutauschende Token) und optional das gewünschte Zielpublikum, den Bereich und den Tokentyp.

1. grant_type: ERFORDERLICH. Der Wert dieses Parameters muss urn:ietf:params:oauth:grant-type:token-exchange sein und angeben, dass ein Tokenaustausch durchgeführt wird.
2. subject_token: ERFORDERLICH. Das PAT des Benutzers.
3. subject_token_type: ERFORDERLICH. Der Typ des Sicherheitstokens, das im Parameter subject_token bereitgestellt wird. Ein häufiger Wert dieses Parameters ist urn:ietf:params:oauth:token-type:access_token, aber er kann je nach dem ausgetauschten Token variieren.
4. resource: OPTIONAL. Der Ressourcenindikator, hilft, die Zielressource für das Zugriffstoken zu spezifizieren.
5. audience: OPTIONAL. Das Publikum des Zugriffstokens, also die beabsichtigten Empfänger des Tokens. Der Autorisierungsserver kann den Wert von resource verwenden, wenn audience nicht angegeben ist.
6. scope: OPTIONAL. Die angeforderten Bereiche.

Die Anfrage muss auch die Clientinformationen enthalten, die als Basic-Auth-Header codiert oder als Formulardaten gesendet werden können.

Hier ist ein Beispiel für eine Anfrage:

Tokenaustausch in Logto#

Logto unterstützt den Tokenaustausch sofort, einschließlich Personifizierung und persönliche Zugriffstoken.