Seite 2: Der Entwurf zur OpenID OAuth Extension

Inhaltsverzeichnis

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.