Menü

Webdesign API-Autorisierung mit OAuth 2

Der OAuth-Standard regelt den Zugriff auf bestimmte Inhalte. Inzwischen gibt es zahlreiche Webangebote, die darauf aufsetzen.
API-Autorisierung mit OAuth 2 © Internet Magazin
API-Autorisierung mit OAuth 2

OAuth 2 ist ein offenes Protokoll, das Anwendungen den gegenseitigen Zugriff auf Daten ermöglicht. Gerade im Kontext der Social-Media-Plattformen gewinnt OAuth 2 an Bedeutung.

Einer der ersten Anbieter, der diese Technologie innerhalb seiner Produkte einsetzt, ist Facebook: Mit dem Zugriffsprotokoll wird beispielsweise geregelt, auf welche Benutzerdaten ein Facebook-Spiel zugreifen darf. Bei dieser Art von Architektur benötigt der Benutzer nur einen Account, der an zentraler Stelle verwaltet wird und hat danach auf alle registrierten Anwendungen Zugriff. Umgekehrt bekommen auch die Anwendungen Zugriff auf einen Teil der Daten, die zentral liegen.

Es gibt inzwischen zahlreiche Webapplikationen, die Facebook als Zugangsverwaltung zu ihrer Anwendung nutzen. Der Anwender registriert sich einmalig mit seinem Facebook-Benutzernamen und dem zugehörigen Passwort. Dann meldet er sich über die Anwendungswebsite bei Facebook an, seine Zugangsdaten werden von Facebook verifiziert und er wird anschließend zum Angebot zurückgeschickt.

Durch die Anmeldung bei Facebook gibt der Benutzer automatisch eine Reihe seiner Facebook-Daten für die Anwendung frei. Darüber hinaus kann das Programm auch Facebook-Funktionen nutzen, beispielsweise um eine Statusmeldung über den erreichten Punktestand an alle Facebook-Freunde zu verschicken.


Anwendungsszenarien

Für OAuth 2 gibt es somit zwei Anwendungsszenarien. Das erste umfasst eine Anwendung - wie etwa ein Spiel -, die auf die Benutzerdaten einer anderen Anwendung zugreift und deren Zugangssystem nutzt. Einen solchen zentralen Dienst offeriert beispielsweise Facebook mit der Graph API. Das zweite Szenario hat Facebook und dessen Zugangsverwaltung als Ausgangspunkt, die anderen Anwendungen, ebenfalls Zugang über die Benutzerverwaltung zu Daten des Benutzers gibt.


Authentifizierungsprozess

Es gibt verschiedene Wege, wie ein Client die Berechtigung zum Zugriff auf die Daten einer Anwendung bekommen kann. Im folgenden Beispiel wird einer der gebräuchlichsten beschrieben: Der Client erfragt die Berechtigung, auf Daten einer anderen Webanwendung zuzugreifen. Für unseren Fall treffen wir die Annahme, dass Facebook die Authentifizierungsstelle ist. Dies könnte aber genauso gut ein alternativer Dienst, wie etwa Twitter oder Google, sein.

Viele Webangebote wie etwa Fab nutzen Facebook oder andere Dienste zur Authentifizierung. © Internet Magazin
Viele Webangebote wie etwa Fab nutzen Facebook oder andere Dienste zur Authentifizierung.

Im ersten Schritt greift der Benutzer auf die Webanwendung zu. In dieser findet er eine Schaltfläche "Login über Facebook", die den Zugang zur Anwendung freigibt. Mit dem Anklicken der Schaltfläche wird der Benutzer auf den Anmeldedialog von Facebook geleitet, in dem er seine Benutzerdaten eingibt.

An dieser Stelle kommt die Rückfrage, ob der Benutzer der Anwendung Zugriff zu seinen Daten geben will. Dieser Frage stimmt der Benutzer zu, da er ansonsten keinen Zugang zu der Anwendung erhält. Damit ist die Authentifizierung abgeschlossen und der Benutzer wird auf Basis der "Redirect URI", welche die Client-Anwendung an Facebook übermittelt hat, wieder zur ursprünglichen Anwendung zurückgeleitet.

Der Austausch dieser Information wird in der Regel über einen Registrierungsprozess abgewickelt, in dem der Entwickler der Client-Anwendung diese beim Authentifizierungsdienst anmeldet und die "Redirect URI" bekanntmacht.

Während dieses Registrierungsprozesses erhält die Client-Anwendung in der Regel auch eine Client-ID sowie ein Client-Passwort für den späteren Prozessablauf. Der Benutzer kehrt anschließend auf die Seite zurück, welche in der "Redirect URI" adressiert wird.

Als Hintergrundaktivität kontaktiert die Client-Anwendung den Facebook-Server und schickt den Authentifizierungscode sowie die Client ID und das zugehörige Passwort. Facebook sendet daraufhin ein Zugangstoken an die Client Anwendung und gewährt darüber den Zugang zur Anwendung.


OAuth-2-Rollen

OAuth 2 kennt insgesamt vier unterschiedliche Rollen für den Benutzer und die Anwendung. Die erste Rolle ist der Besitzer der Daten (Resource Owner). Dies kann beispielsweise ein Benutzer bei Facebook oder einer anderen Anwendung sein, die OAuth 2 unterstützt. In den meisten Fällen ist der Besitzer der Daten somit eine reale Person.

Die zweite Rolle ist der Datenserver (Resource Server), auf dem die Daten des Benutzers liegen. Der Server, auf dem sich die Facebook-Daten des Benutzers befinden, kann ebenfalls diese Rolle übernehmen.

Die dritte Rolle ist die Client-Anwendung (Client Application), die den Zugriff auf die Daten anfragt, die sich auf dem Datenserver befinden. Ein Beispiel für eine solche Anwendung ist ein Spiel, das Zugriff auf das Facebook-Konto anfragt.

Der Berechtigungsserver (Authorization Server) ist die vierte Rolle. Dieser entscheidet auf Basis der hinterlegten Berechtigungen, ob eine Client Anwendung Zugang zu den Daten des Benutzers erhält. Ein Server kann beide Rollen - Daten und Berechtigungen - übernehmen, dies ist jedoch keine Notwendigkeit.

OAuth 2.0 legt auch keine Standards fest, wie diese beiden Server miteinander kommunizieren sollen, falls dies zwei unterschiedliche Server sind. Dies kann durch die Entwickler der jeweiligen Anwendung individuell entschieden und umgesetzt werden.


Verschiedene Clients

Die Grafik zeigt den Ablauf einer Anmeldung zwischen einer Client-Anwendung und Facebook. © Internet Magazin
Die Grafik zeigt den Ablauf einer Anmeldung zwischen einer Client-Anwendung und Facebook.

Innerhalb eines Clients trifft OAuth 2 weitere Unterscheidungen, was die Typen und Profile betrifft. Das Protokoll kennt zwei Arten von Client-Typen: öffentliche (public) sowie vertrauliche (confidential). Ein Client mit diesem Status gibt das Client-Passwort, das ihm vom Berechtigungsserver zugewiesen wurde, an niemanden weiter.

Der öffentliche Client behält es prinzipiell auch für sich, ist aber anfälliger gegen Angriffe. Das Passwort wird in der Anwendung gespeichert und ist dort für andere sichtbar. Damit laufen solche Anwendungen natürlich immer Gefahr, Opfer eines Überfalls zu werden.

OAuth 2 klassifiziert darüber hinaus die Anwendungen auf Basis der Implementierung und nutzt dafür drei Profile: Webanwendung, User Agent und Native. Eine Webanwendung läuft auf einem Webserver und besitzt in der Regel darüber hinaus eine gewisse Anwendungslogik. Sieht die Anwendung den Zugriff auf einen Datenserver vor, dann wird das Passwort entsprechend auf dem Server der Webanwendung gespeichert - der Client besitzt somit den Status "vertraulich".

Eine User-Agent-Anwendung läuft innerhalb des Browsers des Benutzers und kann ein Spiel in Flash, HTML5 oder Javascript sein. Die Anwendung wird einmalig von einer Website heruntergeladen und speichert an dieser Stelle auch die Client-ID und das Passwort. Diese Anwendung ist somit öffentlich.

Native Programme werden speziell für eine Plattform entwickelt und müssen in der Regel vor der ersten Verwendung installiert werden. Auch bei diesen Anwendungen wird das Passwort auf dem Client abgelegt.


Berechtigungen

Die weiteren Unterscheidungen finden auf Basis von Berechtigungsmodellen statt, denn bevor eine Anwendung Zugriff auf eine Serverressource erhält, benötigt sie die entsprechende Freigabe. Bei OAuth 2 wird diese als "Authorization Grant" bezeichnet. Wie bereits gesehen, erhält die Anwendung im Autorisierungsprozess eine Client ID sowie ein "Client-Geheimnis" (Client Secret) zugewiesen, bei dem es sich um nichts anderes als ein Passwort handelt.


Berechtigungsfreigabe

Die Freigabe auf die Daten wird einer Anwendung vom Inhaber der Daten zugestanden, wobei die Ausführung zwischen dem Berechtigungsserver und dem Datenserver abgewickelt werden. OAuth 2 kennt insgesamt vier Methoden der Berechtigungsfreigabe, die sich durch unterschiedliche Eigenschaften im Bereich Sicherheit unterscheiden:

  • Beim Berechtigungscode loggt sich der Benutzer beim Autorisierungsserver, zum Beispiel Facebook, ein und erhält nach Freigabe seiner Daten Zugang zur Anwendung. Mit dem Zurückleiten zur ursprünglichen Anwendung schickt der Server einen Berechtigungscode. Dieser fungiert gemeinsam mit der Client-ID und dem entsprechenden Passwort als Zugangsdaten. Auf Basis dieser Informationen stellt der Autorisierungsserver ein Zugangstoken aus.
  • Die implizite Berechtigung unterscheidet sich nur unwesentlich vom Zugang über den Berechtigungscode, ist allerdings im Kommunikationsprozess weniger aufwändig. Nach dem Einloggen in den Autorisierungsserver erhalten Sie direkt den Autorisierungscode samt Zugangstoken.
  • Passwortfreigabe durch den Besitzer der Daten: In diesem Fall würden Sie der Client-Anwendung direkt die Zugangsdaten zum Berechtigungsserver überlassen. Dieses Verfahren ist sehr risikobehaftet und erfordert ein hohes Maß an Vertrauen gegenüber der Client-Anwendung.
  • Berechtigungsnachweis des Client (Client Credentials): Dieses Szenario wird eingesetzt, wenn die Client-Anwendung Zugriff auf Informationen auf dem Datenserver benötigt, die keinen Besitzer haben.


Endpunkte

OAuth 2 kennt drei verschiedene Arten von Endpunkten, die unterschiedliche Aufgaben übernehmen: Berechtigungsendpunkt, Token-Endpunkt sowie Umleitungsendpunkt. Technisch gesehen ist ein solcher Punkt ein URI einer Website und kann beispielsweise durch eine PHP-Seite oder ein Java-Servlet dargestellt werden.

Die Endpunkte für die Berechtigungen sowie das Token verweisen auf eine Website, die auf dem Berechtigungsserver liegt, der Umleitungsendpunkt hingegen liegt auf Seiten der Client-Anwendung.

Beim Berechtigungsendpunkt loggt sich der Besitzer der Daten ein und erteilt der Client-Anwendung die entsprechende Zugriffsberechtigung. Der Token-Endpunkt sorgt für die Bereitstellung des Berechtigungscodes, der Client-ID, des zugehörigen Passworts sowie des Zugangstokens. Der dritte Endpunkt wird in der Client-Anwendung angesteuert, nachdem die notwendigen Zugangsberechtigungen erteilt worden sind.


Anfragen und Antworten

Die Kommunikation zwischen dem Client, der um Zutritt bittet, und dem Server, der diesen gewährt, findet auf Basis von http statt. Es gibt innerhalb dieser Kommunikationsstrecke insgesamt vier unterschiedliche Arten der Anfragen, die Sie in den vorherigen Szenarien bereits kennengelernt haben. Anfrage und Antwort laufen, wie zuvor gesehen, jeweils nach einem vorgegebenen Schema ab.


OAuth 2 und Facebook

Am Beispiel von Facebook und der Graph API zeigen wir, wie die Zugangssteuerung auf Basis von OAuth 2 implementiert wurde. Die Realisierung nutzt eine der einfachsten Formen des Zugangs, der ohne SDK funktioniert und die Zugangsdaten auf Seiten des Client ablegt. Diese Vorgehensweise sollten Sie in der Praxis aus Sicherheitsgründen nicht verwenden. Sie dient in diesem Fall nur der Demonstration der Funktionsweise.

Im Beispiel wird eine URL zusammengebaut, die den folgenden Aufbau besitzt:

https://www.facebook.com/dialog/oauth? client_id=IHRE_APP_ID &redirect_uri=REDIRECT_URI &scope=LISTE_VON_BERECHTIGUNGEN_MIT_ KOMMA_GETRENNT &response_type=token



Innerhalb der URL sind die bereits bekannten Objekte enthalten: Sie übergeben Ihre App-ID, die Redirect URI sowie eine Liste von gewünschten Berechtigungen. Im Gegenzug erhalten Sie das Zugangstoken. Das Beispiel baut im ersten Schritt diese URL aus den verschiedenen Elementen zusammen und setzt die Anfrage ab, falls dies noch nicht gemacht wurde.

Hat bereits eine Anfrage für das Zugangstoken stattgefunden, dann wird dieses verwendet, um Ihre Facebook-Benutzerdaten abzufragen. Aus diesen Benutzerdaten wird der Name ausgelesen und in einer persönlichen Begrüßung verwendet.

Weitere Informationen zur Facebook Graph API und dazu, wie Sie diese sinnvoll in Ihre Anwendung einbinden, finden Sie in der Facebook-Entwicklerdokumentation .

Einfacher Zugang zu Facebook-Daten mittels OAuth 2.0


<html> <head> <title>Oauth 2.0 Beispiel</title> </head> <body> <script> function Benutzeranzeigen(user) { var Benutzername = document.getElementById('Benutzername'); var Begruessung = document.createTextNode('Schoene Gruesse, ' + user.name + '.'); Benutzername.appendChild(Begruessung); }



var appID = YOUR_APP_ID; if (window.location.hash.length == 0) { var pfad = 'https://www.facebook.com/dialog/oauth?'; var queryParams = ['client_id=' + appID, 'redirect_uri=' + window.location, 'response_type=token']; var query = queryParams.join('&'); var url = pfad + query; window.open(url); } else { var accessToken = window.location.hash.substring(1); var pfad = "https://graph.facebook.com/me?"; var queryParams = [accessToken, 'callback=Benutzeranzeigen']; var query = queryParams.join('&'); var url = pfad + query;



var script = document.createElement('script'); script.src = url; document.body.appendChild(script); } </script> <p id="Benutzername"></p> </body> </html>

 
x