Das Protokoll zur Authentifizierung mit OpenID unter der Lupe

Es gibt viele -meist sehr oberflächliche- Erklärungen wie OpenID technisch im Detail funktioniert. An einem konkreten Beispiel soll nochmal die Funktionsweise anschaulich erklärt werden.

Gehen wir von folgender Situation aus: Sie möchten sich auf der Webseite AboutUs mit ihrere ObenID anmelden. Webseiten bei denen man sich mit der OpenID anmelden kann, werden auch als Service Consumer oder Relying Party bezeichnet (Liste von Relying Partys).

Ihre OpenID haben Sie z.B. über den Dienst myOpenID registriert. Dienste welche die OpenID ausstellen, speichern und verwalten werden auch als Identity Provider oder Identity Server bezeichnet (Liste von Identity Provider).

In unserem Beispiel kommuniziert die Relying Party AboutUs mit dem Identity Provider myOpenID. Im OpenID-Protokoll stehen dafür vier Nachrichten zur Verfügung:

• associate Nachricht
  Wird direkt vom Consumer an den Identity Provider gesendet um einen geheimen Schlüssel zu vereinbaren und auszutauschen. Somit müssen folgende Nachrichten zwischen Consumer und Provider nicht ständig über extra Schritte verifiziert werden. Das Protokoll legt nicht fest, ob überhaupt und zu welchem Zeitpunkt die Nachricht associate vom Consumer versendet wird. Es obliegt dem Consumer, wann er diese optionale Nachricht über die HTTP POST Methode versendet.
• checkid_setup Nachricht
  Wird vom Consumer über indirekte Kommunikation (HTTP Browser-Redirect über GET-Methode) an den Identity Provider versendet. Mit dieser Nachricht prüft der identity Provider, ob der User auch tatsächlich der ist, der er behauptet zu sein (assertion).
• checkid_immediate Nachricht
  Ist identisch zu der Nachricht checkid_setup mit dem Unterschied, dass die Antwort nicht als HTTP-Browser-Redirect gesendet wird. Somit können asynchron arbeitenden Ajax-Anwendungen die Kontrolle übernehmen und das Ergebnis in einem eigenen IFrame oder Popup-Fenster darstellen.
• check_authentication Nachricht
  Mit dieser Nachricht verifiziert der Consumer ob die bestätigte Behauptung auch tatsächlich vom Identity Provider stammt. Diese direkte HTTP-POST Kommunikation ist nicht notwendig, wenn über die associate-Nachricht bereits die geheimen Schlüssel ausgetauscht wurden und damit ebenso die Echtheit des Identity Providers festgestellt werden kann. Somit werden die offensichtlichen Hacking- und Phisingversuche unterbunden.

Technischer Ablauf der Authentifizierung am Beispiel AboutUs und myOpenID

	1. Aufruf Consumer Webseite AboutUs Der Benutzer in der Mitte des Bildes ruft mit seinem Browser die Webseite AboutUs auf. Er möchte auf dieser Seite etwas schreiben und muss sich dazu anmelden. Auf dem Login-Screen erhält er ein Feld um seine persönliche OpenID-URL als Benutzername einzugeben.
	2. Login Consumer Request Der Benutzer gibt z.B. die OpenID-URL blog.doubleSlash.de als Login ein. Ein Passwortfeld wird nicht angezeigt. Das Formular wird mit der eingegebenen OpenID-URL an den die Webseite AboutUs gesendet.
	3. Discovery Die Webseite AboutUs kontaktiert nun die eingegebene OpenID-URL unter https://blog.doubleslash.de. Dort ist die Adresse des OpenID-Servers und der zugehörigen OpenID im Quelltext der HTML-Seite eingetragen. Damit weiß die Webseite AboutUs, an welchen OpenID-Server mit welcher OpenID sie sich wenden soll.
	4/5. Associate Request (Optional) Die Webseite AboutUs kann den OpenID-Server kontaktieren um einen geheimen Schlüssel (Shared Secret) auszutauschen bzw. einen vorhandenen Schlüssel zu aktualisieren. Nicht jede Consumer Webseite möchte die ausgetauschten Schlüssel lokal verwalten und verzichtet deshalb auf diesen Schritt. Der Schritt 7 muss dann immer ausgeführt werden. Dies erfordert jedoch zusätzliche Kommunikation.
	4. checkid_setup oder checkid_immediate Request Die Webseite AboutUs kontaktiert den OpenID-Server unter der Adresse http://www.myopenid.com/server mit der OpenID http://doubleSlash.myopenid.com. Der Request geschieht mit einem http-Redirect Aufruf (Code 302) über den Browser des Benutzers.
	5. Login OpenID-Server Request/Response Wenn der Benutzer im OpenID-Server noch nicht angemeldet ist, muss er sich einmalig mit seinem Passwort anmelden. Da der OpenID-Server die Webseite bisher nicht kennt, gibt der Benutzer an ob diese vertrauenswürdig ist. Die Kommunikation mit dem OpenID-Server ist verschlüsselt.
	6. id_res oder cancel Response Egal, ob die Anmeldung am OpenID-Server myOpenID erfolgreich war oder nicht, leitet dieser die Antwort per http-redirect oder als XML (Abhängig ob setup oder immediate Nachricht verwendet wurde) an die Webseite AboutUs weiter (Indirekte Kommunikation).
	7. check_authentication Request/Response War die Anmeldung erfolgreich, baut die Webseite AboutUs eine direkte (verschlüsselte) Verbindung zum OpenID-Server myOpenID auf. Die Webseite verifiziert, ob die erhaltenen Anmeldedaten valide sind und auch tatsächlich von dem OpenID-Server myOpenID stammen (Anti-Phising). Dieser Schritt kann entfallen, wenn in Schritt 4/5 ein Schlüssel ausgetauscht wurde.
	8. Login Consumer Response Der Loginvorgang zum Consumer wird abgeschlossen, indem der Benutzer auf die Seite von AboutUs weitergeleitet wird, welche nach dem Login-Screen vorgesehen ist. Dies kann z.B. eine „Herzlichen Willkommen Herr doubleSlash“ sein.

Weitere Links und Details zum Protokoll:

• OpenID pros und cons
• Sieben Argumente für und gegen OpenID