29.06.2021 | Thomas Bühler
Modern Authentication – Token Exchange
Moderne Authentisierungsprotokolle sind in Zeiten von Cloud und zunehmender standortübergreifender Zusammenarbeit nicht mehr wegzudenken. Nachdem Kerberos jahrzehntelang den Benchmark in der On-Premise-Welt setzte, verabschiedete OASIS im Jahr 2002 SAML V1.0 und ermöglichte somit erstmals eine standardisierte SSO-Integration von Webanwendungen. Im Jahr 2005 stellten dann Brad Fitzpatrick und Johannes Ernst der Welt OpenID Connect als weiteres Web-SSO-Protokoll vor. Fortan bestanden die beiden Web-SSO-Verfahren und die immer noch weitverbreiteten Legacy-Protokolle nebeneinander.
Moderne, hybride IT-Verbundsystemansätze erfordern eine Interaktion über eine Multi-Protokoll-Single-Sign-On-Infrastruktur, die die nahtlose Übergabe von Authentisierungsinformationen gewährleisten muss. Bisher waren Entwickler gezwungen, eigene Lösungen für diese Aufgabenstellung zu entwickeln. Die Ansätze reichen dabei von der Einbettung von Kerberos-Tickets in die Authentication Statements einer SAML Assertion bis hin zu zahlreichen proprietären Konzertierungsdiensten.
Erste Standardisierung durch RFC 8693
Im Januar 2020 wurde der RFC 8693 OAuth 2.0 Token Exchange durch Microsoft, Ping Identity, Yubico und Visa über die Internet Engineering Task Force (IETF) publiziert. Darin enthalten ist ein Lösungsansatz, der die nahtlose Konvertierung von Security Tokens ermöglicht. Dies ist besonders interessant, da der Trend zunehmend von der SOAP-WS-Trust-Welt der OASIS in Richtung Webentwicklungen mit RESTful-Patterns (Representational State Transfer) und JSON geht. Bei der http-basierten Autorisierung von Drittanbieterzugriffen auf RESTful-Ressourcen werden immer öfter das OAuth 2.0 Authorization Framework und die damit verbundenen OAuth 2.0 Bearer Tokens eingesetzt, da unter anderem das Protokoll für mobile Anwendungsfälle besser geeignet sowie allgemein schlanker und flexibler ist.
Im Rahmen des Konvertierungsprozesses nach RFC 8693 validiert der neu eingeführte Security Token Service (STS) die ihm zur Verfügung gestellten Angaben und Antworten mit einem Ersatztoken. Damit können Clients entsprechende Zugriffe auf Ressourcen in heterogenen Umgebungen oder über Sicherheitsdomänen hinweg tätigen. Die entsprechende Ansteuerung des Diensts erfolgt dabei über eine Protokollerweiterung des Standards OAuth 2.0, die bestehende und den meisten RESTful-Entwicklern vertraute Kommunikationsmuster und Datenformate verwendet.
Als Ausgangslage für den Konvertierungsprozess dient der Token Exchange Request. Der Client sendet eine entsprechende Anfrage an den Token Endpoint mit einem speziellen Erweiterungstyp unter Verwendung der HTTP-POST-Methode. Mittels grant_type urn:ietf:params:oauth:grant-type:token-exchange wird dem Dienst mittgeteilt, dass ein Token ausgetauscht werden soll. Dabei ist es erforderlich, dass bei der auf der JavaScript Object Notation (JSON) basierten Serialisierung der Parameter subject_token die Identität der Partei enthält und der Parameter subject_token_type die Art des bestehenden Sicherheitstokens referenziert. Optional können weitere Werte wie resource, audience, scope, requested_token_type, actor_token und actor_token_type übergeben werden, die dann bei der Konvertierung prioritär berücksichtigt werden.
Wurde die Anfrage korrekt beim STS platziert, antwortet dieser mit der Rückgabe eines Access-Tokens über den namensgleichen Parameter access_token. Dabei werden die üblichen OAuth 2.0 Responses vom Token Endpoint verwendet, wie dies von anderen OAuth-Abläufen her bereits bekannt ist.
Bei der Antwort wird dem Client zuerst die technologische Referenz des Antwort-Tokens mittels issued_token_type und das anzuwendende Einsatzverfahren über token_type mitgeteilt. Das Besondere hierbei ist, dass zurückgegebene Tokens keine OAuth-Zugriffstokens sein müssen. Es können beliebige Token für beliebige Anmeldeverfahren zurückgegeben werden, sofern der Token Endpoint dafür ausgelegt ist und über die technischen Voraussetzungen sowie eine entsprechende Verbundintegration verfügt. Weitere Werte wie expires_in, scope und refresh_token können auf dem Token Endpoint konfiguriert werden, um die Originalwerte fallspezifisch zu übersteuern. Dabei gilt es, die Legitimität der Anfrage auf dem Token Endpoint jeweils zu überprüfen.
Fazit und Stand der Umsetzung
Das im RFC 8693 OAuth 2.0 Token Exchange beschriebene Verfahren bietet eine interessante Möglichkeit für den standardisierten Austausch von Token in einem direkten Verfahren. Darüber hinaus stehen weiterhin proprietäre Lösungsansätze zur Verfügung, wie beispielsweise die Verwendung von SPNEGO-based Kerberos Authentications, um die Anmeldung eines OAuth 2.0 Authorization Code Flow auf dem Identity Provider zu automatisieren.
Aktuell unterstützen ZITADEL des Schweizer Unternehmens CAOS AG sowie Ping Identity als weltweiter Anbieter den OAuth 2.0 Token Exchange nach RFC 8693. Auth0 plant die Umsetzung noch in diesem Jahr. Red Hat Keycloak verfügt derzeit über eine eigene Lösung auf Web-Services-Basis, hat jedoch angekündigt, in Zukunft den Standard RFC 8693 auch zu unterstützen.
Es bleibt also spannend, wie sich der junge Standard entwickelt. Wir von der Temet bleiben dran und halten sie auf dem Laufenden.
Identity Federation Security Architecure Strong Authentication
