© DrHitch/Shutterstock.com
OAuth 2.0

1 OAuth 2.0 - die Clientseite


Facebook, Google, Foursquare oder Pinterest haben eines gemeinsam: Die APIs dieser Dienste setzen allesamt auf OAuth 2.0. OAuth 2.0 ist ein Protokoll zur Autorisierung von API-Zugriffen, beispielsweise durch server- oder clientseitige Webanwendungen oder mobile Apps. Trotz des spektakulären Rückzugs von OAuth-2.0-Editor Eran Hammer werden wohl auch in Zukunft mehr und mehr APIs auf dieses Protokoll setzen: OAuth 2.0 hat sich bereits bei den großen Services (Google, Facebook) etabliert und ist im Vergleich zu OAuth1 viel einfacher zu benutzen. Wir betrachten zunächst den wichtigsten OAuth 2.0 Grant, den Authorization Code Grant.

Zugegeben: Der Blog Post, mit dem sich Eran Hammer von der OAuth-2.0-Spezifikation verabschiedet hat [1], war für viele schockierend zu lesen. Als Hauptgrund für seinen Rückzug gibt er „Indecision Making“ an, also das Fehlen von Entscheidungen. Die OAuth-2.0-Spezifikation sei wegen der Mitwirkung zu vieler Parteien zu offen, zu viele Bereiche seien absichtlich ungenau gehalten und diverse Implementierungsmöglichkeiten offen zu halten. Viele dieser Gründe sind im Kern sicherlich richtig. Dennoch bewegt sich die Welt der APIs mit großen Schritten in Richtung OAuth 2.0. OAuth 2.0 ist ein sicheres und gut durchdachtes Protokoll, auch wenn manche sich vielleicht Details besser spezifiziert gewünscht hätten. Und auch wenn die APIs von Google und Facebook derzeit und vielleicht auch für immer nicht hundertprozentig standardkonform sein werden: OAuth 2.0 – in leicht unterschiedlichen Ausprägungen – ist bereits überall im Einsatz. In diesem Kapitel möchte ich nicht allzu lange philosophieren. Fakt ist, dass Kenntnisse über OAuth 2.0 relevanter sind denn je. Egal ob Mobile, klassischer Webclient oder moderne In-Browser-JavaScript/HTML5-App – um den Clientcode zu autorisieren und damit mit Zustimmung des Anwenders auf seine Ressourcen zuzugreifen, benutzt man OAuth 2.0. Und auch wenn die verschiedenen OAuth-2.0-kompatiblen APIs noch leichte Unterschiede aufweisen, so muss man OAuth 2.0 nur einmal aus der Vogelperspektive verstanden haben.

Der erste Teil dieses OAuth-2.0-shortcuts geht auf die Sicht der OAuth-2.0-Clients ein und stellt Ihnen besonders den allgegenwärtigen OAuth 2.0 Authorization Code Grant vor. Im Laufe des Textes werden zahlreiche Codebeispiele die praktische Anwendung aus der Sicht des Clients und Servers beleuchten. Die Codebeispiele für die Benutzung aus Sicht des Clients sind dabei einer Gaelyk Webapplikation entnommen, und meistens handelt es sich um Code aus Gaelyk-Controllern. Weitere Informationen zu Gaelyk, einem schlanken Webframework für Google App Engine, finden Sie unter [2]. Neben den OAuth-2.0-„Flows“ erhalten Sie auch Informationen dazu, welcher Flow für welches Anwendungsszenario am besten geeignet ist.

Rollen

Um OAuth 2.0 besser verstehen zu können, sollte man die Rollen dieses Autorisierungsprotokolls verstanden haben. Es gibt den Resource Owner, den Resource Server, den Client und den Authorization Server.

  • Der Resource Owner ist oftmals der Endanwender, beispielsweise ein Benutzer, der auf seine in der Cloud gespeicherten Bilder zugreifen möchte.
  • Der Resource Server ist ein Server, auf dem die Daten/Dienste des Resource Owners vorliegen. Diese Ressourcen sind dadurch geschützt, dass der Resource Server ein so genanntes Access Token verlangt. Nur wenn das Access Token validiert werden konnte, genehmigt der Resource Server den Zugriff.
  • Der Client ist eine Applikation, die für den Resource Owner auf die Daten/Dienste zugreift. Um auf diese zugreifen zu können, muss er im Besitz eines Access Tokens sein.
  • Der Authorization Server vergibt die Access Tokens, die den Zugriff auf den Resource Server ermöglichen, nach erfolgreicher Authentifizierung des Resource Owners und dessen Autorisierung für den entsprechenden Client.

Der Client stellt also für den Resource Owner Anfragen (HTTP-Requests) an den Resource Server. Damit der Client auf die Daten des Resource Owners zugreifen kann, muss dieser in der Anfrage ein Access Token mitschicken. Das Access Token autorisiert den Client, auf diese Daten zuzugreifen. Der Resource Server kommuniziert dann mit dem Authorization Server, um sicherzustellen, dass das gesendete Access Token valide ist.

Der Authorization Server und der Resource Server sind oftmals das gleiche System. Der Check der Access Tokens geschieht also über interne Methodenaufrufe. Bei größeren APIs kann der Authorization Server auf einem getrennten System laufen. Mit welchem Protokoll dann die Resource Server auf den Authorization Server zugreifen, ist allerdings implementierungsspezifisch. Die OAuth-2.0-Spezifikation hat diesen Teil nicht näher beschrieben.

OAuth 2.0 aus der Vogelperspektive

OAuth 2.0 definiert mehrere so genannte Protocol Flows. Diese Flows sind notwendig, da unterschiedliche Clients unterschiedliche Anforderungen und Möglichkeiten haben. Beispielsweise kann eine serverseitige Webapplikation einen gemeinsamen Schlüssel geheim halten – der Schlüssel ist Teil des Codes auf dem Server und kann normalweise nicht einfach ausgelesen werden. Anders verhält es sich bei den immer populärer werdenden clientseitigen HTML5-Applikationen, die diverse APIs direkt per JavaScript aus dem Browser heraus aufrufen. Der JavaScript-Code kann sehr einfach eingesehen werden. Somit sollte auch kein gemeinsamer Schlüssel darin abgelegt werden. Die vier Flows haben Folgendes gemeinsam:

  • Zuerst wird immer ein Authorization Grant eingeholt. Der Authorization Grant ist die Zustimmung des Resource Owners, dass ein Client auf die Daten des Resource Owners zugreifen kann. Dieser Grant kann ein Code, also ein Stück Text sein, den der Client nach einer erfolgreichen Authentifizierung und Autorisierung des Resource Owners durch den Authorization Server geschickt beko...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang