Step2-Protokoll: OpenID und OAuth Hand in Hand

Inhaltsverzeichnis

Googles OpenID-OAuth-Erweiterung – als hybrides Protokoll unter dem Namen Step2 bekannt – birgt das Potenzial, das globale Dorf "Internet" weiter zusammenrücken zu lassen. Sie ermöglicht es dem Anwender, verschiedene Serviceangebote unterschiedlichster Dienstleister zu kombinieren, ohne dass er sich x-mal auf verschiedenen Webseiten einloggen muss, letztlich sogar, ohne überhaupt Kenntnis darüber zu haben, dass er Angebote mehrerer Anbieter nutzt.

Zwei Artikeln auf heise Developer sprachen schon die Themen Authentifizierungsdienste mit OpenID und OpenID als Java-Bibliothek an: Ein OpenID-Provider stellt dem Anwender ein eindeutiges Login zur Verfügung. Wenn nun eine OpenID-fähige Anwendung vorliegt, lässt sich dieses Login zur Authentifizierung nutzen. Betritt der Anwender später eine weitere Webseite einer ebenfalls OpenID-fähigen Anwendung, ist ein neuerliches Login nicht erforderlich. Neben Single Sign-On, der reinen Überprüfung von Benutzername und Passwort, kann der Provider weitere Informationen über den Anwender speichern, wie ein Flag "Über 18" oder die vollständigen Daten des Personalausweises. Sind diese Informationen für eine Anwendung freigeben, ermöglicht das zum Beispiel eine Altersüberprüfung.

Der sogenannte dreibeinige OAuth-Typ dient dagegen der Autorisierung von Funktionen zwischen verschiedenen Anwendungen beziehungsweise von Services mit einer Endnutzer-Interaktion. So stellt ein Service-Provider wie Googles Picasa einen Dienst zur Verfügung, den ein authentifizierter und autorisierter Endnutzer über seine Konsumenten-Anwendung (zum Beispiel der Online-Fotodruckservice von Aldi) nutzen darf. In diesem Szenario wird eine Authentifizierung vor der Autorisierung durchgeführt.

Im Kontext von OpenID und OAuth stehen dem Endanwender zwei Szenarien zur Verfügung:

Szenario 1: Der für die zugreifenden Services zuständige Service-Provider ist nicht derjenige, der die OpenID-Authentifizierung zur Verfügung stellt. Ein Beispiel: Der Service-Provider Picasa erfordert ein OpenID-Login, bevor der Anwender auf die angebotenen OAuth-Services zugreifen kann. Dabei möchte der Anwender gegebenenfalls MyOpenID als OpenID-Provider nutzen. Dazu muss er sich dort zunächst anmelden. Anschließend darf er auf die Services des OAuth-Service-Providers (Picasa) zugreifen. Der ganze Vorgang wirkt durch die Weiterleitung zum OpenID-Provider komplex und wenig transparent für den Anwender.

Szenario 2: Der OpenID-Provider ist gleichzeitig derjenige, der die OAuth-Services anbietet. Ein Beispiel: Der OAuth-Bilderservice Picasa fungiert gleichzeitig als OpenID-Provider. Der Nutzer meldet sich zunächst bei seinem OpenID-Provider (Picasa) an, anschließend darf er auf die Bilderservices des Dienstes zugreifen. Der Prozess lässt sich noch optimieren, um die zu durchlaufenden Schritte zu verkürzen und damit zu vereinfachen. Genau an dieser Stelle kommt die Kombination von OpenID und OAuth ins Spiel.

In Step2, dem Hybridprotokoll aus OpenID und OAuth, wird die Authentifizierung, beziehungsweise das Einloggen, über OpenID vom OAuth-Service-Provider umgesetzt. Das heißt, der OAuth-Service-Provider fungiert gleichzeitig als OpenID-Provider. Ziel ist es, die Anzahl durchzulaufender Bildschirmmasken in der Webapplikation zu minimieren, um den Anwender schneller zu seinem eigentlichen Geschäftsprozess zu führen. Das steigert die Benutzerfreundlichkeit der Webapplikation, insbesondere wenn man berücksichtigt, dass ein Großteil heutiger Webapplikationen nur relativ einfache Geschäftsprozesse abbildet – Stichwort "Bestellvorgang", bei dem schon ein bis zwei eingesparte Bildschirmmasken einen durchaus hohen Prozentsatz an den Gesamtmasken ausmachen.

Der Entwurf zur OpenID OAuth Extension

Ein weiteres Beispiel aus der Praxis: Google hat seine Data-APIs (OAuth-Services), darunter die zu Google Contact, und das OpenID-Login mit dem genannten Hybrid-Protokoll versehen. Die Webanwendung Plaxo möchte davon nun Gebrauch machen. Es entsteht das folgende Interaktionsszenario:

Der Benutzer loggt sich über Googles OpenID zum ersten Mal in die Plaxo-Anwendung ein. Auf der ersten Seite der Applikation soll der Inhalt des Google Contacts "Kontaktliste" angezeigt werden. Die OAuth-Services des Google-Contact-APIs müssen direkt danach aufgerufen werden. Statt zunächst den OpenID-Mechanismus und anschließend getrennt den OAuth-Workflow zu durchlaufen, hat die Plaxo-Anwendung die Möglichkeit, diese Schritte in einem zusammenzufassen. Dazu wird der Anwender auf der Seite mit zwei Fragen konfrontiert:

• Darf die Plaxo-Anwendung auf die Authentifizierungsdaten von Google (OpenID) zugreifen und verlinken?
• Darf die Plaxo-Anwendung auf die Kontaktdaten von Google Contacts (OAuth) zugreifen?

Abbildung 3 zeigt die Kombination von OpenID und OAuth. Das Zusammentragen der Authentifizierung und Autorisierung ist auf jeden Fall sinnvoll, da es den Benutzer direkt mit allen Folgen seiner eventuellen Freigabe konfrontiert und so die Benutzerfreundlichkeit der Anwendung steigt.

Der Entwurf zur OpenID OAuth Extension

"The OpenID OAuth Extension describes how to make the OpenID Authentication and OAuth Core specifications work well together." – Eigentlich ist mit diesem, der Einleitung der Spezifikation entnommenen Zitat alles gesagt, wie so häufig steckt der Teufel aber im Detail. Denn eins zu eins ist die Funktionsweise der beiden Formate nicht umzusetzen, OAuth muss geringfügig angepasst werden.

Grundsätzlich geht man derart vor, die Authentifizierung und Autorisierung gleichzeitig zu ermöglichen. Im Hybrid-Protokoll ist OAuth als OpenID-Erweiterung definiert. Der Namespace für diese Erweiterung lautet dementsprechend http://specs.openid.net/extensions/oauth/1.0. Dabei ändert sich jedoch das Autorisierungsverfahren von OAuth ein wenig. So findet die Serverkommunikation nicht mehr über ein Request-Token statt, welches von der Konsumenten-Anwendung (im Beispiel oben: Plaxo) zum Service-Provider (hier: Google) gesendet wird, stattdessen versendet der Service-Provider innerhalb der OpenID-Authentifizierung ein schon bestätigtes Request-Token. Aus diesem kann die Konsumenten-Anwendung dann ein Access-Token ableiten, mit dem sie auf die privaten Ressourcen des Service-Providers zugreift. Die Zusammenfassung verkürzt – wie oben dargestellt – die Anzahl von Bildschirmmasken, die der Benutzer durchlaufen muss.

Google hat die Entwicklung des Step2-Protokolls vorangetrieben und stellt ein Anwendungsbeispiel zur Verfügung.

Exkurs zu OAuth 2.0 und OpenID-Connect

Exkurs zu OAuth 2.0 und OpenID-Connect

Inzwischen liegt die Version 2.0 (Draft) von OAuth vor und gleichzeitig unterstützen einige Service-Provider (Google, Facebook und Twitter) Teile dieser Spezifikation. Der Schwerpunkt der neuen Entwicklung ist die Vereinfachung des Protokolls sowie die Bereitstellung neuer Nutzungsszenarien (siehe auch Using OAuth 2.0 to Access Google APIs und Introducing OAuth 2.0).

Bisher war unter anderem die Integration von OAuth 1.x in eigene Anwendungen problematisch (vergleiche das Beispiel im Artikel Autorisierungsdienste mit OAuth auf heise Developer). Ohne OAuth 1.x war es möglich, mit einem einzigen GET-Befehl einen Serviceaufruf auszuführen. Hier mit dem Nachteil, dass Benutzername und Passwort anzugeben waren. Nach der Einführung von OAuth 1.x braucht man für den gleichen Zugriff auf einen Service meistens eine OAuth-Client-Bibliothek, ein einzeiliger GET-Befehl geht nicht mehr.

Nun hat die Entwickler-Community den Wunsch geäußert, einen einfachen Zugriff ohne Eingabe eines Benutzernamen und Passwortes ermöglichen zu können. Zudem sei das Signieren einer Anfrage für viele Entwickler viel zu kompliziert. Abhilfe schafft das jetzt eingeführte "Bearer Token". Das Konzept erlaubt es, mit einem einfachen GET-Befehl einen unsignierten Service-Zugriff über HTTPS durchzuführen. (Das Konzept der Bearer Token gab es schon in OAuth 1.0a, es wurde jedoch nicht als explizite Option erwähnt und ihm daher keine wichtige Rolle zugeteilt.) Mit den durchgeführten Vereinfachungen geht OAuth 2.0 sicherlich in die richtige Richtung, allerdings gehen auch Gefahren mit dem neuen Mechanismus einher.

OAuth 2.0 soll zudem zusätzliche Anwendungsfälle (bekannt als "Flows", Szenarien zur Abholung von Zugriffstoken) unterstützen: OAuth 1.x verstand sich ursprünglich mit Web-, Desktop- und Mobil-Anwendungen. Im Endeffekt liefert die OAuth-1.x-Spezifikation jedoch nur ein einziges Szenario mit drei unterschiedlichen Client-Anwendungstypen. Für Webanwendungen ist das benutzerfreundlich genug, doch für Desktop- oder gar Mobil-Anwendungen ist es zu wenig, da es dort an einer guten Benutzerführung fehlt. Dies ändert sich jetzt mit OAuth 2.0, das gleich mehrere Anwendungsfälle unterstützt:

• User-Agent-Szenario: Geeignet für Konsumentenanwendungen, die in einem Webbrowser laufen, ein Beispiel sind JavaScript-Anwendungen.
• Webserver-Szenario: Geeignet für Konsumentenanwendungen, die auf einem Webserver laufen und auf die per HTTP-Anfrage zugegriffen werden kann. Dieses Szenario entspricht dem bisher bekannten OAuth 1.0 in vereinfachter Form.
• Device-Szenario: Dieses Szenario ist für mobile Geräte geeignet.
• Benutzername-und-Passwort-Szenario: Die Kombination aus Benutzername und Passwort ist die Basis für das Vertrauen zwischen Konsumentenanwendung und Benutzer. Das Szenario eignet sich für Betriebssysteme, das heißt, dass der Benutzername und das Passwort bei der Anfrage des Zugriffstoken mit verschickt werden.
• Client-Credentials-Szenario: Das Szenario entspricht dem bisher bekannten OAuth 1.0 in der Form eines zweigliedrigem OAuth.
• Assertion-Szenario: Die Konsumentenanwendung verwendet eine SAML-Assertion (Security Assertion Markup Language), um ein Zugriffstoken zu bekommen.

Inzwischen haben sich die Ablaufdefinitionen geändert, nähere Informationen dazu in der derzeit aktuellen Spezifikation.

Letztlich verspricht OAuth 2.0 auch eine bessere Performanz und Aufgabenverteilung: Die Stellen, an denen die Anfrage- und Zugriffstoken angefordert werden können, sind in zwei Bereiche unterteilt, was eine klarere Trennung der Zuständigkeiten erlaubt.

Im Prinzip stellt OAuth 2.0 eine Weiterentwicklung des bisherigen Protokolls dar. Für die Implementierung stehen derzeit noch wenige fertige Bibliotheken zur Verfügung, erwähnenswert für Java-Entwickler ist das Framework Spring Social mit OAuth 2 (ausschließlich als Framework "für OAuth-Konsumenten") und das Framework Spring Security mit OAuth 2 (sowohl als OAuth-Konsumenten- wie auch OAuth-Service-Provider-Framework).

Zu OpenID-Connect existiert derzeit eine einzige Website. Das System sollte als "die nächste Generation von OpenID" fungieren und beruht komplett auf OAuth 2, auf dessen Grundlage die Spezifikation von OpenID-Connect fußt. Der Kopf hinter dieser Entwicklung ist David Recordon, von Anfang an in die OpenID-Spezifikation involviert. Seine Idee beruht auf der Tatsache, dass OpenID 1.x teilweise komplex und schwierig zu implementieren sei. Sämtliche OpenID-Abläufe sollten auf OAuth-2-Abläufen aufbauen, wozu man einen OAuth-Scope namens openid angibt. Generell sollen später sämtliche anderen OpenID-Mechanismen über das Scope-Konzept abgebildet werden – die weitere Entwicklung von OpenID-Connect bleibt daher spannend.

Zusammenfassung und Ausblick

Zusammenfassung und Ausblick

Das Hybrid-Protokoll Step2 ist eine kleine und sinnvolle Erweiterung für OpenID und OAuth, mit dem Ziel, die Schritte für Authentifizierung und Autorisierung zusammenzufassen, sodass der Anwender weniger Bildschirmmasken durchlaufen muss und somit die Benutzerfreundlichkeit der Webanwendung erhöht wird. Sicherlich ist der Einsatzbereich des Protokolls eingeschränkt, da es ausschließlich in einem speziellen Anwendungsfall Verwendung findet.

Die beiden Techniken OpenID und OAuth – und die Kombination beider Verfahren – bringen frischen Wind in das Thema Authentifizierung und Autorisierung im Internet. Ohne sie sind integrierte Webapplikationen, die auf unterschiedliche Services unterschiedlicher Service-Provider zugreifen, nicht realisierbar (sofern man eklatante Sicherheitsrisiken vermeiden oder zumindest keine potenziell teuren Benutzerdaten über einen Anbieter zum nächsten reichen mag). Ebenso wären Erweiterungsmechanismen für Webapplikationen (in Form von Plug-ins für Googles WebApp-Framework) kaum umsetzbar. Hier seien als Beispiel die Google Apps mit ihrem Apps Marketplace genannt. Ohne OpenID und OAuth können die Plug-in-, beziehungsweise Erweiterungsmechanismen der Google Apps nicht funktionieren. (Zum Plug-in-Konzept für die Webanwendungen siehe Inside-Out and Outside-In Integration of Webapps: Services and Extensions)

Mit der Entwicklung von OAuth 2.0 und dem OpenID-Connect-Protokoll, welches inzwischen auf OAuth basieren sollte, lassen sich heute beide Protokolle zusammenführen oder wenigstens die Zusammenarbeit beider Protokolle vereinfachen. Und je einfacher die Protokolle umzusetzen sind, desto mehr Akzeptanz haben sie bei den Entwicklern und umso mehr Anwendungen (Web, Mobil, Desktop) werden sie unterstützen. Die größte Frage ist derzeit, welche Protokolle und Versionen für die Authentifizierung und/oder Autorisierung zu unterstützen und überhaupt zu verwenden sind.

OAuth 2 ist für Autorisierungen definitiv zu bevorzugen. Für Single Sign-On und Authentifizierungen sollte ebenfalls OAuth 2 verwendet werden, ein Ansatz, den Twitter mit Sign-in with Twitter und Facebook mit Facebook Connect ebenfalls gewählt haben. Zukünftig dürfte OpenID-Connect einige Erfolge erzielen, da dieses Protokoll auf OAuth 2 basiert.

Dr. Lofi Dewanto
arbeitet als Softwareentwickler bei der Deutschen Post Com GmbH. Er engagiert sich insbesondere für "javanische" Open-Source-Software sowie MDA.

Dipl.-Wirt. Inform. Manuel Klein
arbeitet als Senior-Berater bei der MT AG in Ratingen. Neben der "klassischen" Programmierung im Java-EE-Bereich beschäftigt er sich mit der Android-Programmierung. (rl)