Flexible und sichere Internetdienste mit OAuth 2.0

Inhaltsverzeichnis

Persönliche Daten und Internetdienste werden von einer Vielzahl unterschiedlicher Geräte aus genutzt. Explosionsartig stieg in den letzten Jahren die mobile Nutzung, aber auch Spielkonsolen und Unterhaltungsgeräte sind zunehmend vernetzt. Gefragt sind Techniken zum sicheren Zugriff auf solche Daten. Das Protokoll OAuth 2.0 empfiehlt sich als grundlegender Baustein, da es die Implementierung flexibler und sicherer Internetdienste ermöglicht und dem Benutzer jederzeit die Kontrolle über seine Daten gibt.

Ein Internet-Produkt muss Kunden heute mehr bieten als den Zugriff auf ihre Inhalte über eine Webseite. Apps für unterschiedliche Smartphone-Plattformen sind selbstverständlich, und am besten können die Kunden ihre Inhalte, wie bei Google und Twitter, auch aus anderen Angeboten heraus nutzen. Diesen Anforderungen kommt typischerweise eine HTTP-API nach, die den Zugriff aus eigenen und den Anwendungen Dritter auf die Inhalte der Kunden erlaubt. Hierbei stellt sich die Kernfrage: Wie lässt sich eine solche API gegen Missbrauch absichern, ohne Kunden und Entwickler unnötig zu behindern? Das einfach zu verwendende Sicherheitsprotokoll OAuth 2.0 bietet hierfür passende Antworten, die zudem gute Gründe dafür liefern, warum Branchengrößen wie Google und Facebook darauf setzen.

Die Autoren dieses Artikels stellen das Protokoll auf Basis eigener Erfahrungen in Implementierung und Betrieb von OAuth-Diensten vor und geben einen Ausblick auf die weitere Entwicklung. Sie sind oder waren an der Entwicklung und dem Betrieb von Identity-Management-Diensten (IDM) für Privatkundenprodukte der Deutschen Telekom beteiligt (beispielsweise T-Entertain oder Telekom-Cloud). Der Konzern betreibt seit 2008 Token-basierte IDM-Dienste zur Absicherung von APIs und Apps. Die dabei gesammelten Erfahrungen hat er in die Entwicklung des OAuth-Standards bei der Internet Engineering Task Force (IETF) eingebracht.

Apps, Apps, Apps

Ein typischer Internetdienst benötigt heute ein Portal und eine Vielzahl von Apps für die Nutzung diverser Smartphone-Plattformen und PCs. Eine weitverbreitete Architektur zeigt die Abbildung 1. Die langlebigen Daten der Benutzer liegen in einer Cloud, die eine REST API für den Zugriff von den diversen Clients zur Verfügung stellt. Wie wird nun der Zugriff auf die Daten authentifiziert und autorisiert? Die naheliegende Antwort ist, Benutzername und Passwort mit jeder REST-Anfrage mitzusenden.

Das hat aber diverse Nachteile: Die Prüfung des Passworts und die Abfrage der Benutzerberechtigungen müssen mit jedem Aufruf erfolgen. Das erhöht insbesondere in verteilten Umgebungen die Laufzeit jedes einzelnen Aufrufs. Langfristig viel schwerwiegender ist allerdings, dass die API an bestimmte Benutzer-Credentials und damit auch an einen bestimmten Zugriffskanal gebunden wird.

Wenn zum Beispiel ein Dienst in Fernsehgeräte integriert werden soll, stellt man schnell fest, dass Benutzername und Passwort für die Eingabe mit einer Fernbedienung ungeeignet sind. Eine PIN wäre vielleicht besser, oder man wählt einen sogenannten Split-Screen-Ansatz, bei dem die Authentifizierung auf einem anderen Gerät durchgeführt wird. Jede Änderung an der Authentifizierung würde bei der direkten Einbindung von Benutzername und Passwort in die Signatur der API einen Umbau der API und damit Mehrkosten und Zeitverlust nach sich ziehen. Viel schöner wäre doch, wenn man diese Details aus dem Design der API heraushalten könnte.

OAuth 2.0 bietet durch die Nutzung sogenannter Access Tokens ein Mittel an, um die Implementierung einer API von der eigentlichen Authentifizierung des Benutzers und der Autorisierung des Zugriffs zu trennen.

Dritte und Passwörter

Eine weitere Herausforderung ergibt sich bei der Nutzung von Daten bei einem Dienstanbieter im Kontext eines anderen. Als Beispiel könnte man sich vorstellen, dass ein Benutzer sein Adressbuch bei einem E-Mail-Anbieter auf einer Fotoseite verwenden möchte, um seinen Freunden Einladungen zuzusenden. Für den E-Mail-Anbieter ist das Szenario verlockend, da es die Relevanz der bei ihm verwalteten Daten und damit die Bindung des Benutzers an seinen Dienst erhöht. Gleichzeitig entstehen aber Sicherheitsrisiken. Denn wie sichert er den Zugriff auf die Adressdaten ab?

Typischerweise würde die Fotoseite den Benutzer nach seinen Credentials beim E-Mail- Anbieter fragen und diese dann für den Abruf der Daten benutzen (siehe Abb. 2). Dadurch ergibt sich das grundsätzliche Problem, dass eine fremde Seite das Passwort des Benutzers verarbeitet. Selbst wenn man davon ausgeht, dass die Fotoseite sorgsam mit dem Passwort umgeht und es insbesondere nicht speichert (was ja für Folgezugriffe praktisch wäre), kann es einem Angreifer in die Hände fallen. Dazu reicht es zum Beispiel aus, unabsichtlich Passwörter in Logfiles zu schreiben.

Dieses sogenannte "Password Anti-Pattern" war ein wichtiger Treiber hinter der Entwicklung von OAuth. Das Protokoll stellt sicher, dass immer der jeweilige Dienstanbieter die Benutzer-Credentials prüft. Des Weiteren garantiert er, dass die Identität des Benutzers nicht bekannt gegeben wird – es sei denn, der Benutzer wünscht das explizit.

Nutzer im Mittelpunkt

Ende 2009 begannen die Arbeiten an der OAuth-Version 2.0. Basis waren die Erfahrungen mit OAuth 1.0a und anbieterspezifischen Techniken wie Googles ClientLogin und AuthSub. Ziel war es, ein Protokoll zu schaffen, das von kleinen Installationen mit einem einzigen Dienst bis hin zu großen mit vielen unterschiedlichen Diensten skaliert und dabei so einfach zu benutzen ist, dass es jeder Entwickler – und nicht nur Sicherheitsexperten – implementieren und nutzen kann.

Die Einfachheit wurde durch einen vollständigen Verzicht auf digitale Signaturen innerhalb des Protokolls erreicht. Seine Sicherheit beruht vielmehr auf der konsequenten Verwendung von HTTPS, Zufallswerten und der Einmalnutzung bestimmter Parameter. Die Skalierbarkeit hat ein ganzes Paket an Maßnahmen verbessert. Zum einen ermöglicht der konsequente Einsatz von HTTPS den Verzicht auf Nonces (einzelne Zahlen- oder Buchstabenkombinationen, die nach einmaliger Verwendung verworfen werden) zur Vermeidung von Replay-Angriffen. Damit lassen sich serverseitige Implementierungen komplett zustandslos realisieren. Des Weiteren wurde das Protokoll nachhaltig modularisiert und lässt jetzt für das Design konkreter Implementierungen weitaus mehr Freiraum als die Version 1.0. Damit ist es sowohl für die Absicherung einfacher Dienste als auch für große Installationen mit vielen Diensten geeignet.

Abbildung 3 zeigt die Entitäten des OAuth-2.0-Protokolls und den abstrakten Protokollablauf. Das grundlegende Prinzip von OAuth ist die Benutzerkontrolle. Im Mittelpunkt steht der Schutz von Ressourcen eines Benutzers, zum Beispiel Dokumenten oder Adressbucheinträgen, vor unbefugtem Zugriff. Daher werden Benutzer als Resource Owner bezeichnet. Die Ressourcen verwaltet wiederum ein Resource Server. Von ihm erwartet man, dass er nur vom jeweiligen Benutzer autorisierte Zugriffe akzeptiert und durchführt. Die Autorisierung repräsentieren Access Tokens, die ein vertrauenswürdiger Authorization Server im Namen des Benutzers ausstellt. Als Voraussetzung authentifiziert der Authorization Server den Benutzer und holt dessen Autorisierung für die Durchführung des Zugriffs ein. Als Client bezeichnet man jede Anwendung, die im Auftrag des Benutzers auf geschützte Ressourcen desselben zugreift.

Der Client erhält nur Zugriff auf die Daten des Benutzers, wenn dieser vorher zugestimmt hat. Hierzu sendet der Client einen Authorization Request (1) an den Resource Owner. Das kann bedeuten, dass der Client den Benutzer direkt nach Benutzername und Passwort fragt. Es kann sich aber auch um eine Anfrage handeln, die via Browser-Weiterleitung über den Authorization Server als Mittler durchgeführt wird. Wenn der Benutzer dem Zugriff zustimmt, erhält der Client einen korrespondierenden (2) Authorization Grant ausgehändigt. Abbildung 4 zeigt beispielhaft einen Dialog für eine solche Zustimmung. Den Grant sendet der Client an den Authorization Server (3), der im Gegenzug ein Access Token ausstellt (4). Dieses verwendet der Client dann für die Autorisierung von Aufrufen beim Resource Server (5..n).

Das Access Token erlaubt es dem Resource Server festzustellen, im Namen welches Benutzers der Client agiert und welche Rechte der Benutzer an die Anwendung delegiert hat. Diese Tokens haben eine begrenzte Gültigkeit. Ein neues Access Token kann der Client zum einen durch erneute Rückfrage mit dem Benutzer erlangen, zum anderen lässt sich ein sogenanntes Refresh Token verwenden, welches das Abfragen eines neuen Access Token ohne Benutzerinteraktion ermöglicht. Ein Refresh Token hat eine wesentlich längere Lebenszeit als ein Access Token, lässt sich aber jederzeit vom Benutzer zurückziehen.