OAuth (Open Authorization)

Heutzutage verwenden wir zahlreiche Webseiten, Programme und mobile Apps, um unser privates und berufliches Leben einfacher oder komfortabler zu gestalten. Angesichts dieser großen Vielfalt an Tools ist es inzwischen für viele Menschen normal geworden, die Inhalte einer Anwendungswebsite (zum Beispiel Instagram) auch auf einer anderen Website (beispielsweise Facebook) zu nutzen – also plattformübergreifend zu agieren. Da bei diesen Vorgängen aber eine Menge persönlicher Daten übertragen werden, stellt sich die Frage nach der Sicherheit der eigenen Privatsphäre. Das Autorisierungsprotokoll OAuth soll das Risiko für unbefugten Datenmissbrauch mindern. Kann es dieser Aufgabe gerecht werden?

OAuth, kurz für „Open Authorization“, ist ein offenes Standardprotokoll, das eine sichere API-Autorisierung ermöglicht. Der Programmierer-Fachbegriff API (kurz für „Application Programming Interface“) bezeichnet in diesem Zusammenhang eine Schnittstelle, die als Datenübermittler zwischen verschiedenen Anwendungen, Benutzeroberflächen oder Webseiten fungiert. Eine Autorisierung solcher von APIs durchgeführten Datenübermittlungen ist deshalb erforderlich, weil ohne sie das Risiko besteht, dass unbefugte Dritte die Daten abfangen und für ihre Zwecke missbrauchen.

Das heißt: Soll eine App zum Beispiel im Namen des Nutzers auf Facebook posten (also auf das API von Facebook zugreifen), muss sie eine Erlaubnis dieses Nutzers vorweisen können. Ebenso benötigt eine Anwendung die Vollmacht des Nutzers, um seine Profilinformationen aus einem anderen Dienst ziehen zu können. Mittels OAuth kann der Nutzer solch eine Vollmacht (Autorisierung) erteilen, ohne der autorisierten Anwendung selbst seinen Benutzernamen und sein Passwort mitteilen zu müssen – er behält also die volle Kontrolle über seine Daten.

Anbieter wie Google, Twitter und Facebook können OAuth im Umkehrschluss dazu nutzen, ihre Produkte und Dienstleistungen flexibler und zugleich sicherer zu gestalten, etwa mittels Single-Sign-On-Lösungen. Und auch Amazon und Microsoft zählen inzwischen zum Kreis großer Unternehmen, die OAuth als Standard zur Zugriffsdelegierung für ihre Dienstleistungen nutzen.

Das nicht rückwärtskompatible OAuth2 (auch „OAuth 2.0“ genannt) wurde im Oktober 2012 als vollständige Überarbeitung von OAuth veröffentlicht und hat selbiges inzwischen weitestgehend abgelöst. So unterstützt die Graph-API von Facebook nur noch das neue Protokoll als Autorisierungsstandard. Es dient der Authentifizierungsschicht OpenID Connect (OIDC) als Grundlage.

Prinzipiell ist die Aufgabe von OAuth2 dieselbe wie die seines Vorgängers: mittels API-Autorisierung dem Nutzer mehr Flexibilität bei gleichzeitig hoher Sicherheit zu ermöglichen. Jedoch wurden zahlreiche Schwächen des ursprünglichen Protokolls behoben, die das Coding und die Implementierung umso schwieriger machten, je komplexer die Systeme von Facebook, Twitter und anderen API-Betreibern im Laufe der Zeit wurden.

Abgesehen von einer gänzlich veränderten Terminologie ist die wichtigste Neuerung von OAuth2, dass es im Gegensatz zu seinem Vorgänger keine kryptografischen Signaturen mehr für jede Maschine-zu-Maschine-Kommunikation im Protokollablauf verlangt. Das erleichtert die Anwendung und Erweiterung des Protokolls ungemein. Es bedeutet aber auch, dass das neue Protokoll technisch gesehen weniger sicher ist – ein Fakt, der OAuth2 einiges an Kritik einbrachte.

Open Authorization 2.0 wurde außerdem um stärker differenzierte Genehmigungsprozesse (Grant Types) ergänzt und die Performance des Protokolls verbessert. Das haben die Entwickler dadurch erreicht, dass OAuth2 nicht mehr bei jedem Kommunikationsschritt nach den Zugangsdaten des Nutzers (Resource Owner) fragt, sondern nur bei der erstmaligen Autorisierung der jeweiligen Anwendung (Client). Eine weitere nennenswerte Neuerung sind Access-Token mit kürzerer Gültigkeit, die es einem Dienst (Resource Server) erleichtern, erteilte Autorisierungen wieder zurückzunehmen. Zudem kann der Nutzer unter OAuth2 selbst entscheiden, welche Berechtigungen (scope) er einer Anwendung zugesteht.

Vor allem beim Thema Single-Sign-on (SSO) wird OAuth gern in einem Atemzug mit OpenID und SAML genannt. Zwar geht es bei allen genannten Konzepten um die verlässliche Verifizierung von Nutzeridentitäten, dennoch gibt es große Unterschiede zwischen den drei.

OpenID (kurz für „Open Identification“) ist ein offenes Protokoll: Wenn ein Nutzer sich einen OpenID-Account erstellt, kann er sich mit diesem via Token bei anderen Diensten und Anwendungen anmelden, die ebenfalls OpenID unterstützen. Ein gutes Beispiel hierfür ist der Button „Mit Google anmelden“, den man inzwischen auf vielen Webseiten findet und der ein Single-Sign-on-Verfahren über den Google-Account des Nutzers zulässt.

Somit ist OpenID im Gegensatz zu OAuth strenggenommen kein Autorisierungs-, sondern ein Authentifizierungsstandard. Allerdings sind die beiden Protokolle seit 2014 eng miteinander verknüpft: OAuth 2.0 ist nämlich die Grundlage, auf der die neue Version von OpenID, genannt OpenID Connect (OIDC), aufbaut. OAuth2 erlaubt den verschiedenen Arten von Anwendungen (Clients), die Identität des Nutzers über die Authentifizierung durch einen Autorisierungsserver zu überprüfen – und darüber hinaus, weitere grundlegende Informationen über ihn einzuholen. Im Gegenzug wird das Protokoll um alle notwendigen Funktionen für Login und Single-Sign-on ergänzt. OpenID Connect ist zudem um optionale Funktionen erweiterbar, beispielsweise Session-Management und die Verschlüsselung von Identitätsdaten.

Die offene und XML-basierte Security Assertion Markup Language (kurz: SAML) verbindet gewissermaßen die Eigenschaften der beiden vorangegangenen Konzepte. Bei ihr handelt es sich nämlich sowohl um einen Standard für die Authentifizierung als auch für die Autorisierung. SAML ähnelt in seiner Funktionsweise OpenID und kommt ebenfalls bei Single-Sign-on-Verfahren zum Einsatz.

Um die Funktionsweise des OAuth2-Protokolls zu verstehen, ist eine Übersicht über die darin definierten Rollen und Genehmigungsprozesse hilfreich.

OAuth2 unterscheidet vier Rollen:

• Resource Owner (auch: User, Nutzer): eine Entität, die einem Client Zugriff auf seine geschützten Daten (auch: Ressourcen) gewährt.
• Resource Server (auch: Dienst): ein Server, auf dem die geschützten Daten des Resource Owners gespeichert sind.
• Client (auch: Dritter, Third-Party): eine Desktop-, Web- oder Mobile-Anwendung, die auf die geschützten Daten des Resource Owners zugreifen will.
• Authorization Server: ein Server, der den Resource Owner authentifiziert und einen zeitlich begrenzten Access-Token für einen von ihm definierten Anwendungsbereich (scope) ausstellt. Authorization Server und Resource Server werden in der Praxis häufig zusammen betrieben und dann auch als OAuth-Server bezeichnet.

Weiterhin wird zwischen vier vordefinierten Genehmigungsprozessen (Grant Types) unterschieden, die in verschiedenen Anwendungsfällen zum Einsatz kommen:

• Autorisierungscode (Authorization Code): Der Client bittet den Resource Owner, sich beim Authorization Server einzuloggen. Daraufhin wird der Resource Owner zusammen mit einem Autorisierungscode zum Client zurückgeleitet. Im Austausch für diesen Code stellt der Authorization Server einen Access-Token für den Client aus.
• Implizite Autorisierung (Implicit Authorization): Dieser Genehmigungsprozess ähnelt stark der Berechtigung per Autorisierungscode, ist aber weniger komplex, da der Authorization Server den Access-Token direkt ausstellt.
• Passwortfreigabe durch den Resource Owner (Resource Owner Password Credentials): Hierbei vertraut der Resource Owner dem Client seine Zugangsdaten direkt an, was dem Grundprinzip von OAuth zwar weitestgehend zuwiderläuft, aber für den Resource Owner weniger Aufwand bedeutet.
• Client-Berechtigung (Client Credentials): Dieser besonders simple Genehmigungsprozess kommt dann zum Einsatz, wenn der Client auf Daten zugreifen will, die keinen Besitzer haben oder für die keine Autorisierung erforderlich ist.

Benötigt der Client künftig erneut Zugang zu den geschützten Daten des Resource Owners, kann er einen zwar zeitlich begrenzten, aber deutlich langlebigeren Refresh-Token nutzen, um beim Authorization Server einen neuen Access-Token anzufragen. Dabei ist keine erneute Autorisierung durch den Resource Owner erforderlich.

Konkrete Beispiele für den OAuth2-Protokollablauf liefern die sozialen Netzwerke Pinterest und Facebook. So bietet Pinterest die Option, Kontakte aus Facebook-Freundeslisten zu importieren. Dafür benötigt Pinterest Zugriff auf den jeweiligen Account und die dort hinterlegten Informationen. Aus Gründen der Datensicherheit wäre es jedoch nicht ratsam, den Benutzernamen und das Passwort für Facebook an Pinterest weiterzugeben – schließlich hätte Pinterest dann jederzeit uneingeschränkten Zugang zu allen Daten und Funktionen des Facebook-Accounts. Damit Pinterest trotzdem auf die benötigten Facebook-Daten zugreifen kann, kommt OAuth2 zum Einsatz:

1. Zunächst loggt man sich in seinen Pinterest-Account ein und navigiert im Benutzerprofil zu den Einstellungen.
2. In der Menüleiste „Soziale Netzwerke“ schiebt man nun den Regler neben „Facebook“ auf „Ja“.
3. Pinterest bittet nun darum, sich bei Facebook einzuloggen und die Pinterest-App zu bestätigen. Diese Handlung gilt als Autorisierungsgenehmigung.
4. Pinterest fordert einen Access-Token beim Authorization Server von Facebook an und nutzt diesen anschließend, um auf die geschützten Daten auf dem Resourcer Server zuzugreifen.
5. Die importierten Facebook-Freunde werden nun auch im Pinterest-Account angezeigt.

Dass auch ein für den Schutz persönlicher Daten konzipiertes System wie OAuth nicht hundertprozentig perfekt sein kann, zeigte sich bereits im April 2009, als im Authentifizierungsablauf des Protokolls eine Sicherheitslücke entdeckt wurde. Wie bei vielen anderen solcher Systeme ist auch Phishing ein ständiges Risiko: So wurden zwischen April und Mai 2017 eine Million Gmail-User Opfer einer OAuth-basierten Phishing-Attacke. In einer betrügerischen E-Mail waren sie darum gebeten worden, ihre Autorisierung über ein gefälschtes Interface zu erteilen, um einer angeblichen Anwendung namens „Google Apps“ Zugriff auf ihre Account-Daten zu ermöglichen.

Die Entwicklung der Nachfolgerversion OAuth2 sollte daher nicht nur die Implementierung des zunehmend komplexen Protokolls erleichtern, sondern auch seine Sicherheit erhöhen. Im Oktober 2012 kamen die damit verbundenen Bemühungen zu einem finalen Ergebnis – jedoch ohne eine Absegnung derjenigen Entwickler, die damals beim Original-OAuth mitgeholfen hatten. Lediglich der leitende OAuth2-Redakteur Eran Hammer-Lahav hatte am alten OAuth mitgearbeitet – und selbst dieser distanzierte sich schließlich von dem neuen Projekt, drei Monate vor der Veröffentlichung. In einem Artikel auf seinem Blog hueniverse.com vom 26. Juli 2012 erklärte er die Hintergründe für seine Entscheidung und bezeichnete OAuth 2.0 gleich in der Überschrift als „Weg in die Hölle“.

Was war passiert? Laut Hammer-Lahav war die Entwicklung des neuen Protokolls von ständigen Debatten zwischen den Entwicklern und den beteiligten Unternehmen (u.a. Yahoo!, Google, Twitter und auch der Deutschen Bank) bestimmt gewesen. Streitfragen seien meist zugunsten wirtschaftlicher Interessen irgendwann ignoriert worden. Konsequenz sei ein Protokoll, das laut Hammer-Lahav nicht mehr als solches bezeichnet werden dürfte. Denn statt einen eng definierten Standard darzustellen, sei OAuth2 höchstens ein Framework, das man beliebig anpassen und erweitern könne. Damit hätte OAuth2 aber das Merkmal der Interoperabilität verloren – unterschiedliche OAuth2-Implementierungen seien also nicht zwangsläufig miteinander kompatibel.

Noch eine Sache bedauert Hammer-Lahav: Dass man sich für eine einfachere Implementierung entschieden habe (zum Beispiel durch das Weglassen von Signaturen), führe zu einen Mangel an Sicherheit. Um eine sichere Anwendung programmieren zu können, die OAuth2 unterstützt, müssten Entwickler ein erhebliches Maß an Expertise mitbringen. Wahrscheinlicher sei daher, dass sich künftig schlicht unsichere Anwendungen im Netz häufen würden. Implementierungsfehler seien angesichts der unvollständigen und übermäßig komplexen Spezifikationen unvermeidbar, so Hammer-Lahav.

Mit seinen Befürchtungen hatte Hammer-Lahav zumindest teilweise recht: Im Jahr 2016 beschäftigte sich erstmals eine Forschergruppe von der Universität Trier mit der Sicherheit von OAuth2 und entdeckte dabei zwei Sicherheitslücken. Eine davon ermöglichte Man-in-the-Middle-Attacken. Grundsätzlich schätzten die Forscher das Protokoll aber als verhältnismäßig sicher ein – vorausgesetzt, es sei korrekt implementiert. Das Team hinter OAuth2 hat die Schwachstellen laut eigenen Angaben bereits behoben. Der Forschungsbericht war für viele IT-Experten allerdings Anlass, sich in Artikeln näher mit der sicheren Verwendung von OAuth 2.0 zu befassen.