OpenID

OpenID

Allgemeine Informationen zu OpenID

OpenID ist eine Web-Technologie zur Authentifikation. Technisch gesprochen ist es ein offener Standard in Form eines Authentifikationsprotokoll zur Kommunikation zwischen Internetdiensten und Internet-Nutzern. Die Idee dabei ist, erstens, dem Internet-Nutzer den Umgang mit Internet-Diensten durch die Verwendung eines einzigen Kontos, und damit eines einzigen Kennworts, zu erleichtern. Zweitens sollte der Nutzer frei entscheiden können, welchem OpenID-Provider er vertrauen möchte. Eine weitere Annehmlichkeit ist die Tatsache, dass jedermann ein OpenID-Provider werden kann. Damit wird der Forderung eines dezentralisierten Systems Rechnung getragen.

Sicherheitstechnisch sieht das Protokoll zwei weitere allgemeine Aspekte vor: Zum einen, dass das Kennwort nicht an den Dienstanbieter übertragen wird und zum anderen, dass dem Nutzer zusätzlich die Möglichkeit gegeben wird, darüber zu entscheiden, welchem Dienstanbieter er welche persönlichen Daten zur Verfügung stellt (sharing).

Das Protokoll arbeitet im Kern mit einem sogenannten Identifikator, der einem Nutzer zugeordnet ist und pseudonymisierbar ist. Das oberste Ziel des Protokolls ist es, die Zugehörigkeit des Identifikator zum Nutzer zu prüfen. Als Netzwerkprotokoll dient HTTP(s). So ist sichergestellt, dass keine weiteren Spezialfunktionen beim User-Agent (Browser) erforderlich sind. Cookies und Ajax-Erweiterungen können die Interaktion vereinfachen. Im Folgenden beziehe ich mich auf die OpenID-Spezifikation in der Version 2.0 und speziell auf die Kommunikation mittels HTML-Dokumenten (Alternative: XRDS-Dokumente).

Akteure

OpenID: Ein Satz von Daten.

OpenID-Provider (OP): Verwahrt und administriert die OpenIDs.

Der Internet-Nutzer: Die OpenID ist seine digitale Identität, die er als Dienstleistung vom Provider in Anspruch nimmt.

Der Web-Dienst: Ein Dienst, der durch den Nutzer mittels einer OpenID in Anspruch genommen wird. Hierbei handelt es sich um eine OpenID-fähige Webseite.

Discovery-Server: Bevor die OpenID-Daten vom OpenID-Provider abgefragt werden, werden Metainformationen mit einem Discovery-Server ausgetauscht. Üblicherweise fällt dieser jedoch mit dem OpenID-Provider zusammen.

Struktur des Authentifikations-Protokolls

Vorbemerkung zur Datenstruktur Wie schon erwähnt, wird zur Kommunikation das HTTP(s)-Protokoll benutzt und insbesondere Web-Formulare eingesetzt. OpenID-Daten haben in der Regel die Form openid.<VARIABLE> = '<VALUE>' und sind in der Struktur von Formularfeldern kodiert. Beispiel: <input type=“text“ name=“openid.mode“ value=“associate“>

Die Authentifikation gliedert sich grob in drei Phase: der Initiierungs- und Feststellungsphase (Kennenlernen), der optionalen Assoziationsphase (Kanal aufbauen) und der Phase der Authentisierung bzw. Authentifizierung. Es folgen die Phasen im Einzelnen.

Initiierung- und Feststellung (engl. Discovery)

Nach dem man eine Anfrage zur Benutzung eines bestimmten Web-Dienstes (z.B. E-Mail) gestellt hat, erhält man ein Formular als Antwort. Der erste Schritt ist nun die Eingabe des („claimed“) Identifikators, zum Beispiel zeitgeist09.openid.com. Das Ziel des Ganzen ist es, wie gesagt, die Zugehörigkeit dieses Identifikators zum Nutzer zu überprüfen.

Gleichzeitig ist dieser Identifikator eine Referenz auf eine Informationsseite, auf der sich Meta-Informationen für den Web-Dienst zum Ablauf der Kommunikation befinden: Welche Protokollversion wird benutzt? Wo befindet sich der Namespace, d. h. die eigentliche Informationsquelle? Ist der OpenID-Provider festgestellt, beginnt die (optionale) Assoziationsphase.

(Optionale) Assoziation

Diese Phase ist optional und empfohlen, wenn beide Seiten die Möglichkeit haben, Sitzungsinformationen abzuspeichern. Das Ziel dieser Phase ist der Aufbau eines sogenannten „shared secretes“ zwischen dem Web-Dienst und dem OpenID-Provider. Es handelt sich hierbei um einen MAC-Schlüssel, der später dem Signieren bzw. der Verifizierung von sogenannten Versicherungen (engl. Assertion) dient. Kommuniziert wird mittels direkter HTTP-Requests und -Responds. Web-Dienst und Provider verhandeln nun unter anderem über die Verwendung des Signieralgorithmus (HMAC-SHA1, HMAC-SHA256) und wenn möglich über den Verschlüsselungsalgorithmus (no-encryption, DH-SHA1, DH-SHA256) für die Verschlüsselung des MAC-Schlüssels. Es gibt zwei Möglichkeiten: Entweder wird auf Transportebene verschlüsselt, so dass eine Verschlüsselung des MAC-Schlüssels nicht nötig ist, oder der MAC-Schlüssel wird per DH-SHA1 bzw. DH-SHA256 verschlüsselt. Letzteres funktioniert folgendermaßen:

1. Der Web-Dienst verschickt in einem ersten Request die DH-Parameter: Modul (m), Generator (g) und seinen öffentlichen Schlüssel ($g^{xa}modp$).
2. Der Provider berechnet nun aus dem öffentlichen Schlüssel des Web-Dienstes und seinem privaten Schlüssel den DH-Schlüssel. Nun sendet der Provider in einem Respond die fehlende Diffie-Hellman-Information: seinen öffentlichen Schlüssel ($g^{xb}modp$). Des Weiteren generiert er einen MAC-Schlüssel, den er nun mit dem neuen DH-Schlüssel verschlüsselt: Hash(DH-Schlüssel) XOR MAC-Schlüssel. Wie man sieht, wird der DH-Schlüssel zuvor mit SHA1 bzw. SHA256 gehasht.
3. Der Web-Dienst kann nun auch das „shared secrete“ berechnen. Nun ist er auch in der Lage, den mitgelieferten verschlüsselten MAC-Schlüssel durch eine einfache XOR-Verknüpfung zu entschlüsseln.

Authentifizierung

Im Gegensatz zur Assoziierung erfolgt die Kommunikation zwischen Web-Dienst und Provider immer über den Internet-Nutzer (indirekte Kommunikation). Eine explizite Erklärung gibt es dafür jedoch nicht. Das Ziel dieser Phase ist es nun, Gewissheit in Form einer „Assertion“ zu erlangen über die Zugehörigkeit des Identifikator zum Besitzer. Dazu schickt der Web-Dienst als erstes eine Authentifizierungsanfrage, in der er dem Provider mitteilt,

1. um wen es geht (Nutzer-Identifikator),
2. wer er selber ist, um die Rückumleitung für eine Antwort zu ermöglichen und
3. welche Nutzerdaten er benötigt.

Der nächste Schritt ist im Protokoll nicht spezifiziert und hängt vom Provider ab. Sein Anliegen ist es, die Identität des betroffenen Nutzers zu prüfen, beispielsweise durch die Eingabe eines Kennwortes, um dem Web-Dienst eine negative beziehungsweise positive Versicherung (Assertion) zuzusenden.

Als Antwort erhält der Web-Dienst nun jene Versicherung. Es stellt sich nun die Frage bevor er die Versicherung auswertet, woher er wissen kann, dass diese Versicherung echt ist. Aus diesem Grund muss die Versicherung geprüft werden. Dafür gibt es zwei Wege, die im Folgenden erklärt werden.

Verifikation mittels Assoziation

Voraussetzung hierfür ist die Vollendung der Assoziationsphase und damit die Existenz eines „shared key“. Vier Bedingungen müssen erfüllt sein, damit eine Versicherung von dem Web-Dienst akzeptiert werden kann.

1. Die Rückumleitungs-URL (openid.returnurl) muss gleich seiner eigenen URL sein.
2. Die Informationen aus der Feststellungsphase müssen den Informationen in der Versicherung entsprechen.
3. Die Versicherung, die einen bestimmten Nonce-Wert enthält, wurde zuvor noch nicht von speziell diesem Provider akzeptiert.
4. Die Signatur ist valide und alle Felder, die signiert werden mussten, sind signiert.

Direkter Verifikation über den Provider

Dieser Schritt sollte eher eine Ausnahme darstellen, und zwar für den Fall, dass die Assoziationsphase ausgelassen wurde oder aber die Assoziation nicht mehr gültig ist (Zerfall des „shared secretes“). Unter diesen Umtänden muss der Web-Dienst trotzdem prüfen können, ob die vom Nutzer weitergeleitete Versicherung echt ist. Die Idee dabei klingt im ersten Moment komisch: die erhaltene Versicherung lässt sich der Drittanbieter per direkter Kommunikation nochmals vom selben OpenID-Provider gegenprüfen. Anders ausgedrückt heißt dies, dass die Versicherung vom OpenID-Provider zum Nutzer, vom Nutzer zum Drittanbieter, vom Drittanbieter zum OpenID-Provider weitergeleitet wird und dieser seine eigene Unterschrift prüft und eine direkte Antwort zum Drittanbieter zurückschickt.

Aus technischer Sicht muss dafür die Bedingung erfüllt sein, dass der Provider einen privaten Assoziations-Handle gespeichert hat. Dieses Handle muss in der Versicherung enthalten sein und mit dem Handle selbst unterschrieben sein. Nach Erhalt der Versicherung sendet der Web-Dienst eine Kopie der erhaltenen Versicherungsdaten direkt an den Provider zurück. Dieser verifiziert die exakte Übereinstimmung und prüft auch die von ihm ehemals erstellte Signatur mit dem privaten Assoziations-Handle. Daraufhin sendet er eine direkte Verifikations-Antwort an den Web-Dienst zurück. Die Einschränkung, dass immer nur eine Verifikations-Antwort auf eine Versicherung folgen kann, stellt einen weiterer Sicherheitsaspekt gegen Replay-Attacken dar (dies wird durch einen Nonce-Wert sichergestellt).