OpenID 2.0 erklärt: das ursprüngliche dezentrale Login

OpenID 2.0 war ein offener Standard, mit dem Sie eine einzige Webadresse als Identität auf vielen Websites nutzen konnten. Statt für jede Seite Benutzername und Passwort anzulegen, gaben Sie eine URL ein, die Sie kontrollierten, etwa alice.example.org, und die Seite fragte den Dienst hinter dieser URL, ob Sie tatsächlich ihr Inhaber sind. Verabschiedet wurde er im Dezember 2007; inzwischen hat ihn OpenID Connect abgelöst.

Was war OpenID?

OpenID begann 2005 als Weg, den Besitz einer Blog-Adresse zu belegen, entwickelt von einem Entwickler des Blogdienstes LiveJournal. Die Idee war einfach und radikal: Identität sollte nicht einem Unternehmen gehören. Jeder konnte einen Provider betreiben, jeder Logins akzeptieren, und Nutzer wählten ihren Provider frei oder betrieben sogar einen eigenen.

Das meint „dezentral“ bei OpenID: Es gab kein zentrales Register und keine vorherige Vereinbarung zwischen Website und Provider. Der Spezifikationstext ist auf der Website der OpenID Foundation archiviert.

Wie funktionierte OpenID 2.0?

Drei Rollen waren beteiligt: der Nutzer, der OpenID Provider (OP), der den Nutzer authentifiziert, und die Relying Party (RP), die Website, die ein Login will. Unsere Seite zur Relying Party verfolgt den Begriff von hier bis heute.

1. Kennung eingeben. Der Nutzer tippt im Login-Formular der Website eine OpenID ein, eine URL oder eine XRI.
2. Discovery. Die Relying Party ruft diese URL ab und ermittelt, welcher Provider zuständig ist. OpenID 2.0 nutzte das Protokoll Yadis und XRDS-Dokumente, mit einem Rückfall auf <link>-Tags im HTML der Seite. Ergebnis ist die Endpunkt-Adresse des Providers.
3. Association (optional). Relying Party und Provider können per Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis vereinbaren. Ohne es bittet die Relying Party den Provider später, die Antwort zu bestätigen („stateless“ oder „dumb“ Modus).
4. Weiterleitung. Der Browser wird mit einer Authentifizierungsanfrage, die openid.*-Parameter trägt, zum Provider geschickt.
5. Authentifizierung. Der Provider meldet den Nutzer an, mit Passwort oder anderen Mitteln, und fragt, ob die Identität an diese Seite weitergegeben werden darf.
6. Antwort. Der Provider leitet mit einer signierten Aussage zurück, ebenfalls als URL-Parameter.
7. Prüfung. Die Relying Party kontrolliert Signatur, Nonce und ob der Provider für die Kennung zuständig war.

Delegation

Delegation erlaubte es, eine persönliche URL zu behalten und trotzdem einen fremden Provider zu nutzen. Auf der eigenen Seite stand ein Paar HTML-Links, in OpenID 1.x openid.server und openid.delegate, in 2.0 openid2.provider und openid2.local_id. Relying Parties folgten ihnen zu Ihrem Provider. Wechselten Sie später den Provider, blieb Ihre OpenID dieselbe.

Identifier Select

OpenID 2.0 führte auch Identifier Select ein: Der Nutzer gibt nur die Adresse des Providers ein, etwa eines großen Webunternehmens, und der Provider ergänzt die tatsächliche Kennung des Nutzers. Das machte den Login freundlicher, veränderte aber das Identitätsmodell: Die URL kontrollierte der Nutzer nicht mehr.

Erweiterungen

Das Kern-OpenID sagte nur, dass Sie eine Kennung kontrollieren. Erweiterungen wie Simple Registration und Attribute Exchange transportierten Profildaten wie Name und E-Mail. Ihr Einsatz variierte zwischen Providern, was später der Interoperabilität schadete.

Warum wurde es abgelöst?

• Bedienbarkeit. Eine URL als Benutzername einzutippen verwirrte normale Nutzer. Schaltflächen für große Provider waren einfacher, untergruben aber die offene Idee.
• Phishing. Eine bösartige Relying Party konnte Nutzer auf eine täuschend echte Provider-Seite umleiten.
• Komplexität. Discovery, Association, Erweiterungen und das XRDS-Format waren für Entwickler schwergewichtig.
• Keine Mobil- und API-Geschichte. OpenID gab Websites einen Login, aber keinen Standardweg zum Zugriff auf Nutzerdaten über APIs. Diese Lücke füllte OAuth, und Entwickler begannen, beides zu kombinieren.
• Konkurrenz. Proprietäre Social Logins boten einfachere Abläufe und erreichten riesige Nutzerzahlen.

OpenID Connect, im Februar 2014 fertiggestellt, behielt das Ziel und verwarf den Entwurf. Es baut auf OAuth 2.0 auf, nutzt JSON und signierte Token und gibt Relying Parties standardisierte Claims. Die Geschichtsseiten Warum OpenID verschwand, Von OpenID zu OpenID Connect und die OpenID-Zeitleiste erzählen die Geschichte im Detail.

Abschaltungen und was bleibt

Google gab am 21. April 2015 bekannt, dass die Unterstützung für OpenID 2.0 und mehrere andere ältere Authentifizierungsverfahren beendet sei, und forderte Entwickler zum Umstieg auf OpenID Connect oder OAuth 2.0 auf. Stack Exchange entfernte den OpenID-Login am 25. Juli 2018 mit Verweis auf sehr geringe Nutzung. Manche Dienste akzeptieren OpenID 2.0 noch heute, am sichtbarsten Steam in der Spielewelt.

Behandeln Sie jeden verbliebenen OpenID-2.0-Endpunkt mit Vorsicht: Bibliotheken sind oft nicht mehr gepflegt, und dem Protokoll fehlen moderne Schutzmechanismen.

Beispiele

• Login mit persönlicher URL. Ein Blogger nutzte die eigene Seite als OpenID und delegierte an einen Provider, sodass Kommentare auf anderen Blogs seine Seite zeigten.
• Login über einen Provider. Ein Nutzer klickte eine Schaltfläche eines großen Anbieters, und die Relying Party erhielt über Identifier Select eine Kennung pro Seite.
• Steam-Web-Login. Drittseiten lassen Sie sich per OpenID 2.0 mit einem Steam-Konto anmelden und erhalten dafür eine Steam-ID.

Sicherheitshinweise für alle, die noch darauf stoßen

• Prüfen Sie openid.return_to, Nonce und signierte Felder; Replay- und Manipulationsangriffe waren häufige Implementierungsfehler.
• Vertrauen Sie keinen unsignierten Attributen.
• Setzen Sie überall auf HTTPS; frühe Installationen nutzten reines HTTP.
• Planen Sie die Migration zu OpenID Connect oder, für Nutzer-Logins, zu Passkeys.

Wie fügt es sich in die heutige Landschaft?

Heutige Alternativen beschreibt die Übersicht zur EUDI-Wallet. Der Kerngedanke von OpenID, dass Menschen selbst wählen, wer für sie bürgt, und diese Wahl zwischen Diensten mitnehmen, ist im Wallet-Modell in anderer Form zurückgekehrt: Dort halten Sie die Nachweise selbst.

Stand im Oktober 2026

OpenID 2.0 ist ein Legacy-Standard, der für neue Einsätze nicht gepflegt wird. Die OpenID Foundation konzentriert sich auf OpenID Connect und neuere Arbeiten wie OpenID for Verifiable Credentials. Wir sind ein unabhängiger Ratgeber und nicht mit der OpenID Foundation verbunden.