Zusammenfassung

  • OpenID Authentication 2.0 erlaubte eine vom Nutzer kontrollierte URL als dauerhaftes Kennzeichen. Der dort ausgewiesene OpenID-Provider konnte wechseln, während die URL gleich blieb.
  • Dafür musste die annehmende Website den Provider über diese URL finden, dessen Antwort mit den gefundenen Angaben vergleichen und die behauptete URL als Schlüssel für das örtliche Nutzerkonto behalten.

Eine Webadresse konnte 2007 zur Antwort auf eine heikle Frage werden: Wem gehört eigentlich der Name, unter dem mich andere Websites kennen? Die am 5. Dezember veröffentlichte Endfassung von OpenID Authentication 2.0 ließ eine Person eine URL als Kennzeichen vorlegen. Die besuchte Website, im Protokoll Relying Party genannt, fragte den zugehörigen OpenID-Provider nach einer Anmeldung. Der Provider prüfte die Person; die besuchte Website erhielt eine überprüfbare Antwort. Ihr Passwort musste die Person dieser Website nicht geben.

Der Standard vergab den beiden Seiten der Anmeldung eigene Namen. Der Claimed Identifier bezeichnete die gegenüber der Website behauptete Identität. Ein OP-Local Identifier bezeichnete das Konto beim Provider. Letzterer konnte auf einer fremden Domain liegen und war womöglich gar nicht unter Kontrolle des Nutzers. Wer beides in einen Topf warf, machte aus dem Providerkonto unbemerkt die dauerhafte Identität.

Die Trennung war im HTML einer gewöhnlichen Webseite abbildbar. An der behaupteten URL konnte ein Link mit rel="openid2.provider" auf den Endpunkt des Providers zeigen. Optional konnte rel="openid2.local_id" das dortige lokale Kennzeichen angeben. Eine Person mit Kontrolle über diese Webseite konnte den ersten Verweis auf einen anderen Provider ändern. Die URL, die andere Websites als ihren Namen sahen, musste dabei nicht umziehen.

Das klingt nach einem kleinen Eingriff in eine HTML-Datei. Die eigentliche Last lag bei den besuchten Websites. Eine positive Antwort des Providers durfte nicht bloß deshalb gelten, weil sie technisch wie eine OpenID-Antwort aussah. Der Standard verlangte, dass die Relying Party die behauptete URL auflöst und den antwortenden Provider sowie das lokale Kennzeichen mit den dort gefundenen Angaben abgleicht. War diese Ermittlung vor der Antwort noch nicht erfolgt, musste sie dann nachgeholt werden. Sonst hätte ein beliebiger Provider behaupten können, für die URL einer anderen Person zu sprechen.

Nach der Prüfung kam die zweite, leisere Entscheidung: Unter welchem Schlüssel liegt das lokale Konto? Die Spezifikation empfahl den Claimed Identifier als Schlüssel für lokale Nutzerdaten. Speichert eine Website stattdessen das Kennzeichen des Providers, kann ein Providerwechsel wie eine neue Person aussehen, obwohl die behauptete URL dieselbe geblieben ist. Der Login-Knopf war nur die Oberfläche; die Kontodatenbank entschied über die Kontinuität.

Die Rücksicht auf OpenID 1.1 machte dieses Problem sichtbar. Eine Antwort nach 1.1 enthielt das Feld openid.claimed_id nicht. Wenn behauptete URL und Provider-Kennzeichen auseinanderfielen, musste die Relying Party daher die URL aufbewahren, mit der sie die Ermittlung begonnen hatte, etwa in der Sitzung. Ohne diese Erinnerung konnte sie eine erfolgreiche Prüfung dem falschen örtlichen Konto zuordnen.

Die Mitteilung der OpenID Foundation vom 5. Dezember 2007 stellte die endgültige Authentifizierungsspezifikation zusammen mit dem Attributaustausch vor. Im Kern der Anmeldung steckte eine Machtfrage: Der Name konnte bei seinem Nutzer bleiben, während verschiedene Unternehmen um die Prüfung der Zugangsdaten konkurrierten. Voraussetzung war eine URL unter Kontrolle des Nutzers und eine Website, die die Regeln zum Finden, Prüfen und Speichern tatsächlich ausführte.

Originalquellen