Autorisierungsdienste mit OAuth

Inhaltsverzeichnis

Das OAuth-Protokoll ist nicht so bekannt wie OpenID, spielt jedoch in einigen Webanwendungen für den Datenaustausch und für REST-Webservices bereits eine große Rolle. heise Developer untersucht, welche Formen des Datenaustauschs und welche Integrationsmöglichkeiten OAuth unterstützt.

Mehr Infos

Internet-Identität und Datenaustausch heute – Nutzung und Möglichkeiten von OpenID und OAuth

• Identity Management: Authentifizierungsdienste mit OpenID
• Einführung in die OpenID-Java-Bibliothek openid4java
• Autorisierungsdienste mit OAuth
• OpenID und OAuth: Zusammen für ein besseres Internet?

Die Geburtsstunde von OAuth liegt im Jahr 2007. Das Protokoll findet mittlerweile in vielen konsumentenorientierten Websites wie Yahoo, AOL, Google und Flickr Verwendung. Es ermöglicht dem User (Endnutzer) einer Webanwendung (Service-Provider) private Ressourcen (Protected Resources) wie Fotos, Videos, Kontaktliste und Kontoauszug mit allen anderen Webanwendungen (Konsument) auszutauschen, ohne Nutzername und Passwort der Service-Provider-Webanwendung den Konsumenten-Applikationen preiszugeben. OAuth verwendet ein sogenanntes Token für die Übertragung von Nutzername und Passwort.

Oberflächlich betrachtet ist der Prozess mit dem in OpenID vergleichbar. Beide haben jedoch unterschiedliche Einsatzbereiche. Sämtliche Spezifikationen im OpenID-Umfeld beschäftigen sich mit Authentifizierung und Identitätsmanagement. Eine typische Frage im OpenID-Kontext ist beispielsweise: "Ist die Person, die sich einloggen will, tatsächlich Herr Frank Müller?" OAuth hingegen unterstützt schwerpunktmäßig einen zentralisierten Autorisierungs- und Datenaustauschprozess sowie einen delegierten Aufruf von REST-Webservices (Represential State Transfer) [1]. Wie sich der Nutzer – etwa über einfaches Login mit Name und Passwort oder per OpenID-Authentifizierungsprozess – autorisieren lässt, spielt eine untergeordnete Rolle. Die typische Frage im Kontext lautet: "Darf Herr Frank Müller, der sich korrekt authentifiziert hat, die Fotos seiner Flickr-Anwendung an die Applikation eines Druckdienstleisters Printeria übertragen?"

Da ein Datenaustausch à la "OpenID Attribute Exchange"-Spezifikation ebenfalls möglich ist, benötigt man eine klare Abgrenzung. Eine solche liefert der nächste Artikel der Serie ausführlich. Es ist allerdings wichtig, vorab zu erwähnen, dass OAuth keine OpenID-Erweiterung darstellt, denn es sollten sich unterschiedliche Authentifizierungsmechanismen außer OpenID verwenden lassen. Das bedeutet jedoch nicht, dass das OAuth-Protokoll eine komplette Neuentwicklung ist. Es hat seinen Ursprung in bekannten Autorisierungsmechanismen wie Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Flickr API und Amazons Webservices-API (AWS).

OAuth zu verwenden ist mit der Bezahlung per EC-Karte zu vergleichen. Möchte man in einem Restaurant mit der Karte (Service-Provider) bezahlen (Geld stellt die auszutauschenden Ressource dar), gibt niemals der PIN-Code (Benutzername und Passwort) dem Kellner (Konsument) Bescheid. Stattdessen tippt der Karteninhaber den PIN-Code direkt in das Eingabegerät des Kartenlesers ein. (Ein anderes Beispiel, wie das Zusammenspiel zwischen Service-Provider, Konsument und Endnutzer anschaulich aussehen kann, findet man in Eran Hammer-Lahavs "Beginner's Guide to OAuth".

Die folgende Tabelle beschreibt Rollen und Begriffe in OAuth. Sie dienen als Basis für die Definition des OAuth-Protokolls beziehungsweise die mit ihm einhergehende Spezifikation.

Begriff	Bedeutung
Service-Provider	Ein Service-Provider stellt seine private Ressourcen zur Verfügung, auf die sich von anderen Anwendungen zugreifen lässt. Anzumerken ist, dass ein Service-Provider nicht gleichzeitig derjenige sein muss, der eine Authentifizierung des Endnutzers durchführt. Ein Service-Provider kann die Aufgabe beispielsweise an einen OpenID-Provider weitergeben.
Endnutzer	Ein Endnutzer besitzt private Ressourcen, die er, nachdem er zugestimmt hat, den anderen Webanwendungen zur Verfügung stellen will.
Konsument	Ein Konsument beziehungsweise eine Konsumenten-Anwendung ist eine Applikation, die einen bestimmten Service oder private Endnutzer-Ressourcen eines Service-Providers in Anspruch nehmen will. Die Anwendung kann unterschiedliche Formen annehmen wie eine Desktop-, Mobile- und Webanwendung. Wichtig ist, dass der Entwickler der Anwendung (genannt Konsumenten-Entwickler) sich im Voraus Konsumenten-Schlüssel und -Geheimnis vom Service-Provider besorgt hat und sie in der Konsumenten-Anwendung einbauen muss.
Private Ressourcen	Private Ressourcen können in unterschiedlichen Formen auftreten: Daten (Fotos, Dokumente, Kontakte), Aktivitäten (Blog posten, Geld überweisen) und einfacher URL, der zu schützen ist. Private Ressourcen stellen ein oder mehrere Webservices, meist in Form eines REST-Modells, dar.
Token	Ein Token verwendet man statt des Nutzernamens und des Passworts, um Autorisierung auf privaten Ressourcen zu ermöglichen. Ein Token besteht meistens aus einem zufälligen String (Buchstaben und Zahlen). Es ist eindeutig und schwer zu erraten. Zudem wird es mit einem Konsumenten-Geheimnis kombiniert. OAuth verwendet zwei unterschiedliche Token-Typen: Anfrage- und Zugriffs-Token.