Zusammenfassung

Die Frist gehörte dem Anbieter, das Kontobuch dem Standort

Im Februar 2014 begrüßte Google die Verabschiedung von OpenID Connect und setzte zugleich ein Enddatum für sein altes Anmeldeverfahren: 20. April 2015. Die Firma wollte föderierte Anmeldung auf den neuen Standard ausrichten und bot eigene Integrationswerkzeuge an. Mehr als ein Jahr stand für die Umstellung bereit. Der Zeitraum war dennoch eine Entscheidung des Identitätsanbieters. Ein abhängiger Standort konnte seinen Code anpassen, nicht aber Googles alten Endpunkt nach eigenem Wunsch offenhalten.

Das lokale Konto hatte in der Zwischenzeit Inhalt angesammelt. Ein verifizierter OpenID-2.0-Identifikator konnte zum Schlüssel für Einkäufe, gespeicherte Arbeiten, Mitgliedschaften oder Rechte geworden sein. OpenID Connect beschreibt die Identität dagegen durch ein Paar aus Aussteller und Subjekt. Derselbe Mensch kann mit einem anders geformten Schlüssel erscheinen. Eine neue Anmeldung, die technisch klappt, kann deshalb ein zweites leeres Konto erzeugen. Eine vorschnelle Verknüpfung kann einer fremden Person Zugang zu einer bestehenden Kontohistorie verschaffen.

Google wiederholte die Warnung am 20. März 2015. OpenID 2.0 und mehrere ältere Verfahren sollten am 20. April enden. Anwendungen, die bis dahin nicht umgestellt waren, könnten ihre Verbindung zu Google verlieren; sogar die Anmeldung ihrer Nutzer könne betroffen sein, bis sie ein unterstütztes Protokoll nutzten. Die Nachricht kündigte ein Betriebsrisiko an, keine gezählte Schadensbilanz. Sie machte deutlich, was Google selbst kontrollierte: die Laufzeit des alten Authentifizierungsdienstes.

Vier Tage vor der Abschaltung stand die gemeinsame Regel fest

Die OpenID Foundation meldete am 16. April 2015 28 Stimmen für die endgültige Migrationsspezifikation, keine Gegenstimme und vier Enthaltungen. Bis zu Googles angekündigter Frist blieben vier Tage. Diese Zahl ist nicht die gesamte Entwicklungszeit. Google hatte sein Ziel 2014 bekanntgegeben, und ein Anhang der endgültigen Spezifikation vergleicht deren Regeln mit einem Google-Leitfaden vom Juni 2014. Die vier Tage messen den Abstand zwischen der formellen Billigung eines gemeinsamen Verfahrens und der geplanten Abschaltung des alten Eingangs.

Die Spezifikation trennt zwei Arten von Kennungen. OpenID 2.0 lieferte einen verifizierten Claimed Identifier. Bei OpenID Connect ist die Kennung ein Aussteller-Subjekt-Paar. Ein Standort ergänzt seine Authentifizierungsanfrage um den Geltungsbereich openid2 und fragt so die alte Kennung zusammen mit der neuen an. Kennt der Anbieter den alten Identifikator der Person, setzt er ihn als openid2_id in das ID Token. Der Standort prüft das Token. Dann muss er eine zweite Frage beantworten: Hat dessen Aussteller die Befugnis, gerade für diesen alten Identifikator zu sprechen?

Hier setzt die Schranke an. In einem eng definierten Fall kann der Standort die gleiche Autorität hinter altem und neuem Endpunkt feststellen. Sonst ruft er die alte Identifikator-URI mit Accept: application/json ab und verlangt, dass der zurückgegebene Wert iss genau dem Aussteller des ID Tokens entspricht. Für XRI-Kennungen steht ein eigener Weg bereit. Scheitert diese Autoritätsprüfung, darf der alte Identifikator nicht für die Verbindung akzeptiert werden. Nach bestandener Prüfung soll der Standort das bestehende OpenID-2.0-Konto mit der neuen Kennung verbinden. Das ist ein Eingriff in seine eigene Kontentabelle, nicht in die Oberfläche des Anbieters.

Der Anhang B dokumentiert Unterschiede zum Google-Migrationsleitfaden vom Juni 2014. Dort stand openid.realm, während der endgültige Standard openid2_realm wählte; der alte Wert hieß dort openid_id statt openid2_id. Die Autoren der Spezifikation halten außerdem fest, dass der Leitfaden die im endgültigen Text beschriebenen Prüfungen des anfragenden Standorts und der Autorität über den alten Identifikator nicht ausführte. Das ist ihre Gegenüberstellung mit einem datierten Leitfaden, keine Prüfung aller tatsächlichen Google-Systeme. Sie zeigt, warum eine übertragbare Kontomigration mehr braucht als die Umstellungsanweisung des Unternehmens, das den Termin setzt.

Die Quellen nennen weder eine Zahl abgeschlossener Umstellungen noch eine Zahl falsch verbundener Konten. Dafür wären die Protokolle einzelner Standorte nötig. Die Zuständigkeiten lassen sich gleichwohl sauber lesen: Google konnte ein altes Verfahren beenden; jeder Standort musste beweisen, welchem neuen Schlüssel er seine alten Daten anvertrauen durfte.