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.