Dieser Artikel soll einen kurzen Überblick über OAuth 2.0, SAML 2.0 und OpenID Connect sowie über Tücken beim Durcheinanderbringen von Authentisierung und Autorisierung geben.

OAuth2, OpenID Connect und SAML sind die am häufigsten verwendeten Protokolle, die Authentisierung oder Autorisierung an eine getrennte Instanz delegieren. SAML 2.0, OAuth 2.0 und OpenID Connect werden der Kürze halber als SAML, OAuth2 bzw. OpenID bezeichnet. In einem ersten Schritt wird eine Protokollübersicht gegeben.

OAuth 2.0

OAuth2, für Open Authorization stehend, stellt Mechanismen zur Verfügung, die es einem Benutzer (Resource Owner in OAuth2-Terminologie) erlaubt, einen Dienst (Client) zu autorisieren, auf die Daten des Benutzers auf einem anderen Server (Resource Server) zuzugreifen. Dies wird erreicht, indem entsprechende Berechtigungsnachweise, z.B. ein Access-Token, von einem Authorization Server, dem der Resource Server vertraut, abgerufen werden. Der Client verwendet dann diesen Berechtigungsnachweis, um auf die Daten des Ressourcenservers zuzugreifen. Der Ressourcenserver kann diverse Methoden zur Verifizierung der Authentizität des Berechtigungsnachweises verwenden, wobei die häufigste Methode die Prüfung einer eingebetteten kryptographischen Signatur ist.

Ein gängiges Beispiel zur Veranschaulichung dieser Dynamik ist ein Benutzer, der ein Druckergerät autorisiert, auf seine Fotos in der Google-Cloud zuzugreifen. Die OAuth2-Spezifikation definiert einige Prozesse zur Durchführung dieser Berechtigungsübertragung, um einer Vielzahl von setup-bedingten Anforderungen gerecht zu werden.

Einer der einfachsten ist der Folgende: Ein Drucker möchte auf die Fotos des Benutzers in der Google-Cloud zugreifen und schickt den Benutzer deshalb mit einem Link an Google, der Informationen darüber enthält, wer den Zugriff wünscht, welcher Zugriff gewünscht wird und wohin der Zugriff versendet werden soll, wie zum Beispiel: https://oauth2.google.com/?scope=photos&client_id=bobs_printer&redirect_uri=https://192.168.1.1/. Google Authentisiert den Benutzer beim Besuch des Links und fragt ihn, ob es dem Client bobs_printer Zugriff auf seine Fotos gewähren will. Wenn der Nutzer den Zugriff erlaubt, wird er mit einer URL, die einen Berechtigungsnachweis enthält, wie z.B. https://192.168.1.66/?access_token=SG93IGRvZXMgTW9zZXMgbWFrZSB0ZWE/IEhlIGJyZXdzLiBoZWhlaGVo, auf die Webseite seines lokalen Druckers zurückgeschickt. Der Drucker kann dann dieses Token in Anfragen an den Google Photos Server verwenden, um auf die Fotos des Benutzers zuzugreifen.

SAML 2.0

SAML, Abkürzung für Security Assertion Markup Language, ermöglicht es einem Dienst (Service Provider in SAML-Terminologie), die Authentisierung und Autorisierung eines Benutzers, der auf ihn zugreifen möchte, an einen zentralen Authentisierungsserver (Identity Provider oder IDP) zu delegieren. Wie OAuth2 unterstützt SAML verschiedene Abläufe, um sein Ziel zu erreichen, die in SAML Bindings genannt werden. Obwohl es nicht mit OAuth2 verglichen werden sollte, kann eine SAML-Bindung denselben grundlegenden Umleitungen folgen, die im Beispiel von OAuth2 beschrieben sind. Es gibt jedoch andere Modellannahmen und Vertrauensbeziehungen und das ausgegebene Token ist für den Dienst selber bestimmt. Der IDP liefert dem Dienst ein signiertes XML-Dokument, das Aussagen über die Identität des Benutzers und seine Berechtigungen enthält.

Die drei verschiedenen SAML-Bindungen, die hier vorgestellt werden, sind Artifact-, POST- und Redirect-Binding.

Redirect- und POST-Binding folgen einem Redirect-Schema, wie im OAuth2-Beispiel beschrieben, wobei der Unterschied zwischen den beiden der Ort ist, an dem Protokolldaten übermittelt werden. Bei POST-Binding werden SAML-Nachrichten im Request-Body eines HTTP-POST-Requests übertragen, während beim Redirect-Binding URL-Parameter verwendet werden.

Während bei Redirect- und POST-Binding dem Browser des Benutzers eine signierte XML-Nachricht zur Authentisierung beim Dienstanbieter übergeben wird, wird bei Artifact-Binding nur ein undurchsichtiges Token übergeben, das SAML-Artifact. Wenn der Dienst das Artifact vom Benutzer empfängt, setzt er sich direkt mit dem IDP in Verbindung, um die mit dem Artifact assoziierte XML-Nachricht abzurufen. Die signierte XML-Nachricht enthält die tatsächlichen Authentisierungs- und Autorisierungszusicherungen für den Benutzer. Dieser Ansatz reduziert die exponierte Angriffsfläche erheblich, indem die Möglichkeit eines Angreifers das komplexe XML-Parsing und die Validierung anzugreifen, eliminiert wird. Da der Dienst und der IDP direkt miteinander kommunizieren müssen, erfordert dieser Binding-Typ oft aufwendigere Integration.

OpenID Connect

OpenID erfüllt die gleichen grundlegenden Aufgaben wie SAML. Während es XML zugunsten des webfreundlicheren JSON über Bord wirft, liegt der massgebende Unterschied in der Funktionalität in OpenIDs Unterstützung für das Auffinden und die Interaktion mit potenziell willkürlichen Authentisierungsservern (OpenID Provider). Diese OpenID-Provider-Discovery und Interoperabilität unterscheidet es von SAML, wo IDPs und Dienstanbieter miteinander integriert werden müssen und in der Regel auch starke Vertrauensbeziehungen haben. OpenID baut auf OAuth2 auf, um eine zusätzliche Identitätsschicht bereitzustellen, mit der Benutzer authentisiert werden können. Daher folgt OpenID bei der Delegierung der Benutzerauthentisierung den gleichen grundlegenden Abläufen wie im OAuth2-Beispiel beschrieben. Die primäre Erweiterung die OpenID OAuth2 hinzufügt, ist das ID-Token, eine Datenstruktur, die Aussagen über die Authentisierung eines Benutzers enthält.

Authentisierung vs. Autorisierung

Ein solides Verständnis der Zusicherungen der Authentisierung und Autorisierung zu haben ist wertvoll, um – oft subtile – Fehler bei Lösungsimplementierungen zu vermeiden. OAuth2 ist als Autorisierungsprotokoll konzipiert, während OpenID Connect und SAML auch Authentisierung bereitstellen. Authentisierung beantwortet die Frage, wer eine Entität ist. Autorisierung hingegen besagt, was eine Entität tun darf. Um ein Beispiel zu nennen: Für den Zugriff auf eine Datenbank wird ein Passwort benötigt. Jeder dem das Passwort mitgeteilt wurde ist berechtigt, auf die Datenbank zuzugreifen. Aus Sicht der Datenbank ist jeder autorisiert, der das Passwort vorweist, aber sie kann keine sinnvolle Aussage darüber machen, welche der autorisierten Personen auf die Datenbank zugreift. Eine sichere Authentisierung bietet die Möglichkeit, mit einem hohen Mass an Vertrauen Aussagen über die Identität einer Entität zu machen.

Oauth2 ermöglicht es einer Entität, einen Dienst zu autorisieren, auf die Daten der Entität auf einem anderen Server zuzugreifen. Wenn dieses Autorisierungsprotokoll entweder zur Authentisierung von Benutzern oder zum Abrufen von Daten mit authentisierenden Eigenschaften verwendet wird, welche später in irgendeiner Business-Logik verwendet werden, macht sich eine Applikation potenziell verwundbar. Anhand eines Beispiels lassen sich die Schwierigkeiten der Verwendung von Standard OAuth2 zur Authentisierung veranschaulichen.

Ein Beispiel könnte ein Online-Forum sein, bei dem sich Benutzer authentisieren können, indem sie dem Forum Zugang zu ihrem Social-Media-Profil gewähren, von dem der Forum-Server ihre Identitätsinformationen abruft. Das Forum identifiziert Benutzer anhand ihres Namens und Geburtsdatums. Aus einer rein technischen Perspektive ist dies eine durchaus sinnvolle Nutzung von OAuth2: Der Benutzer autorisiert das Forum, seine Daten von der Social-Media-Site abzurufen. Ein böswilliger Benutzer, nennen wir ihn Jefferson, möchte Forenbeiträge entfernen, die nicht mit seinen Weltanschauungen übereinstimmen. Jefferson kann ein neues Social-Media-Profil erstellen und dabei denselben Namen und dasselbe Alter verwenden wie der Poster des Beitrags, den er entfernen möchte. Nach der Authentisierung am Forum mit dem neuen Social-Media-Profil, sieht das Forum, dass der abgerufene Name und das Alter übereinstimmen und gibt Jefferson die Möglichkeit, die Beiträge der anderen Person zu löschen und sich weiter als diese auszugeben.

Obwohl OAuth technisch einwandfrei genutzt wird, ergibt sich die Schwachstelle offensichtlich daraus, dass die Benutzerdaten nicht eindeutig identifizierend sind, meinen die Forumsentwickler, so dass sie nun auch die Benutzer-UUID von der Social-Media-Plattform abrufen, die einen Social-Media-Benutzer eindeutig identifiziert. Andere Fragen, die die Entwickler möglicherweise nicht gestellt haben, sind, ob andere Social-Media-Plattformen die zur Authentisierung genutzt werden können, UUID’s in einer Weise implementieren, die eine Manipulation durch Benutzer zulässt. Ist das Forum bereit, ihre Sicherheit von willkürlichen Business-Logik-Entscheidungen eines anderen Unternehmens abhängig zu machen? Derartige Fragen müssen geklärt werden, bevor in die Sicherheit der Authentisierung vertraut werden kann.

In der Zwischenzeit bemerkt Jefferson, der übrigens eine Video-Sharing-Webseite besitzt, die auch die Social-Media-Plattform zum Abrufen von Benutzerdaten nutzt, dass sein unbeliebter Forum-Poster ebenfalls ein Konto auf seiner Webseite hat. Das bedeutet, dass Jefferson den Access-Token zum Social-Media-Profil des Benutzers welches seiner Video-Sharing-Webseite zur Verfügung gestellt wurde, nachschauen und beim Zugriff auf das Forum in den Authentisierungsfluss einfügen kann. Jefferson wird erneut mit dem Forum als sein unbeliebter Forum-Poster authentisiert. Aus der Sicht des Forums wurde ein gültiges Access-Token erhalten mit dem Benutzerdaten von der Social-Media-Plattform abgerufen werden konnten. Das Forum geht davon aus, dass aufgrund des Vorliegens eines gültigen Zugriffstokens, die Instanz die das Token präsentiert, tatsächlich der Benutzer sein muss, für den es Daten abruft. Dies ist nun offensichtlich nicht der Fall und veranschaulicht mögliche Fallstricke bei der Vermischung von Authentisierung und Autorisierung oder bei der Annahme des einen von dem anderen. Diese Situation, in der das Forum aufgrund des Zugriffstokens nicht wissen kann, wer auf das Forum zugreift, ist im Wesentlichen die gleiche wie beim Beispiel mit dem Datenbank-Passwort. In diesem Fall wird sie jedoch dadurch verdeckt, dass ein Zugriffstoken nur dann ausgegeben wird, wenn sich der Benutzer authentisiert.

OAuth2 kann einige zusätzliche Einrichtungen bieten, die es sowohl dem Authorization Server als auch dem Resource Server erlauben, einige begrenzte Annahmen über mögliche Abläufe des Autorisierungsprozesses zu treffen. Von diesen wurden zur Beibehaltung der Einfachheit des Beispiels keine Annahmen gemacht. Im Kern handelt es sich bei OAuth2 nichtsdestotrotz um ein Autorisierungsprotokoll.

OpenID baut auf OAuth2 auf, um auch eine sichere Authentisierung zu ermöglichen. Eine Einrichtung, welche es dafür einführt ist das ID-Token, welches Aussagen zur Identität eines Benutzers enthält. Das ID-Token wird von Server geliefert, welcher die Authentisierung des Benutzers durchführt. Dies ist der Hauptunterschied zwischen OpenID und OAuth2. Während der Autorisierungsserver bei OAuth2 nur ein Access-Token für den Resource Server liefert, wird bei OpenID zusätzlich das ID-Token, welches den Benutzer authentisiert, ausgestellt. Da die Struktur eines ID-Tokens spezifiziert ist, kann sich eine “Relying Party” (der Dienst, der die Authentisierung eines Benutzers bei einem OpenID Provider anfordert) auf diese verlassen.

Fazit

Während die zugrundeliegenden Konzepte der Authentisierungs- oder Autorisierungsdelegation in allen drei Lösungen solide sind, nimmt der Spielraum für Fehler mit zunehmenden Konfigurationsmöglichkeiten, welche mit oft subtilen Unterschieden in Vertrauensbeziehungen und Modellannahmen einhergehen, zu. Bei allen drei Lösungen verstecken sich Schwachstellen oft in Details. Bei der Implementierung einer Lösung müssen alle Modellannahmen sorgfältig analysiert werden, um vorhandene Sicherheitslücken aufzudecken.

Über den Autor

Ahmet Hrnjadovic arbeitet seit dem Jahr 2017 im Bereich Cybersecurity, wobei er sich auf die Bereiche Linux, sichere Programmierung und Web Application Security Testing fokussiert. (ORCID 0000-0003-1320-8655)