Der OpenID-Bezeichner von Google unterscheidet sich je nach dem Domainnamen "Consumer". Wie vermeidet man Probleme, wenn sich der Domainname ändern muss?

Question

Ich teste gerade eine OpenID-Implementierung, und ich stelle fest, dass Google eine andere Kennung für verschiedene verbrauchende Hostnamen/Domänennamen sendet, sogar für denselben Benutzer. Beispielsweise sendet Google eine andere Kennung, wenn die anfordernde Site localhost ist, verglichen mit der ID, die sie senden, wenn die anfordernde Site für denselben Benutzer 127.0.0.1 ist.

Hinweis: Ich habe dies nicht mit öffentlichen Domain-Namen getestet, aber ich kann nicht sehen, warum das Verhalten anders wäre.

Mein Anliegen bezüglich des Verhaltens von Google ist, dass, wenn wir uns jemals dazu entschließen, unseren Website-Domainnamen in Zukunft zu ändern, Nutzer sich nicht länger mit der OpenId von Google als Identitätsanbieter anmelden können. Dies scheint ein großes Problem zu sein. Fehle ich etwas oder sind alle OpenID-Konsumenten mit diesem potenziellen Problem konfrontiert?

Ich habe dies auch mit MyOpenId getestet, aber der Bezeichner, den MyOpenId erstellt, ist behoben, so dass dies kein Problem mit ihnen wäre.

Answer 1

Werfen Sie einen Blick auf Google OpenID most important technical issue. Einige Infos dort. Im Grunde eine Verbindung von den Konten Abschnitt stackoverflow.com genommen;)

-sa

Answer 2

Es scheint, dass die OpenID URLs zurück von Google ist abhängig von dem openid.realm Wert, der verwendet wird. Außerdem habe ich gerade versucht, den OpenID-Prozess mit einem Realm auf http://MYREALM und openid.return_to auf http://localhost/openid.php gesetzt, aber eine HTTP 400 Bad Request erhalten. Anscheinend überprüft Google, dass der Bereich die gleiche Domain (und wahrscheinlich Port) wie die URL "zurück zu" hat.

Eine Idee für eine Problemumgehung ist das Speichern der Google Mail-Adresse, die der OpenID zugeordnet ist. Wenn Sie eine Google OpenID anfordern, fordern Sie die E-Mail-Adresse des Benutzers immer über den Attribut-Typ http://axschema.org/contact/email an. Wenn Sie jemals Domains ändern, können Sie die neue OpenID-URL basierend auf der E-Mail-Adresse mit ihrem Konto verknüpfen.

Hinweis: Es ist imperativ, dass Sie die HMAC-SHA1-Signatur überprüfen. Anderenfalls wäre es jedem möglich, mit einer erstellten E-Mail-Adresse zu der OpenID-Checkauth-Aktion Ihrer Webanwendung zurückzukehren, sodass sie das Konto eines anderen übernehmen können, wenn sie die Google Mail-Adresse des Ziels kennen.

Wenn ein Benutzer mit ihrem Google-Konto zum ersten Mal nach dem Einschalten der Anmeldung, die Migrationsverfahren sind:

1. eine POST-Anforderung mit den folgenden Parametern auf https://www.google.com/accounts/o8/ud senden:

    
   +---------------------+----------------------------------+ 
   | openid.ns   | http://specs.openid.net/auth/2.0 | 
   | openid.mode   | associate      | 
   | openid.assoc_type | HMAC-SHA1      | 
   | openid.session_type | no-encryption     | 
   +---------------------+----------------------------------+ 
   

   (ersetzen openid.realm=http://NEWREALM entsprechend)

   Die Antwort wird etwas wie:

   012.351.

    
   ns:http://specs.openid.net/auth/2.0 
   session_type:no-encryption 
   assoc_type:HMAC-SHA1 
   assoc_handle:B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq 
   expires_in:46800 
   mac_key:F5XUXvoYutLvFv4IzJS0diytLmbe 
   

2. Mit der Umleitung auf den Service-URI, https://www.google.com/accounts/o8/ud, Modus ‚checkid_setup‘, stellen Sie sicher, dass die assoc_handle zu senden, die zuvor als gut erhalten wie der E-Mail-Adresse des Benutzers erfordert über Attributaustausch.Mit anderen Worten, sollten Sie die folgenden, zusätzlichen Parameter senden:

    
   +----------------------+----------------------------------------------------------+ 
   | openid.assoc_handle | B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq | 
   | openid.ns.ax   | http://openid.net/srv/ax/1.0        | 
   | openid.ax.mode  | fetch_request           | 
   | openid.ax.type.email | http://axschema.org/contact/email      | 
   | openid.ax.required | email             | 
   +----------------------+----------------------------------------------------------+ 
   

   Die „Rückkehr zu“ Anfrage openid_signed wichtigen Parameter umfassen wird, openid_sig und openid_ext1_value_email.

3. Folgen Sie the OpenID Authentication 2.0 Specification's procedure for generating the signature. Wenn die base64-Codierung der HMAC-SHA1-Signatur nicht mit dem Wert openid_sig übereinstimmt, ist die Signatur ungültig. Beachten Sie, dass der MAC-Schlüssel in diesem Beispiel F5XUXvoYutLvFv4IzJS0diytLmbe ist. Verwenden Sie den von Google gesendeten Server mit der Verknüpfungsanfrage.

 

Google's Federated Login documentation page states dass http://axschema.org/contact/email "[r] equests die Google Mail-Adresse des Benutzers". Vermutlich wird, sobald ein Google-Konto erstellt wurde, die E-Mail-Adresse "Google Mail" festgelegt. Wenn diese Annahme jedoch nicht gültig ist, ist es nicht sicher, dieses Verfahren zu verwenden, da ein böswilliger Benutzer seine E-Mail-Adresse ändern könnte, die vom Föderierten Anmeldedienst an die E-Mail-Adresse des Kontos zurückgegeben wurde, das sie stehlen möchten.

Um auf der sicheren Seite zu sein, senden Sie vor der Aktivierung der neuen OpenID eine E-Mail-Verifizierungsanfrage an die E-Mail-Adresse. Der Verifikationslink würde eine Nonce enthalten, die der neuen OpenID zugeordnet ist. Sobald auf den Link geklickt wird, wird die neue OpenID vollständig dem Konto des Benutzers zugeordnet, da der Empfang der Nonce die Verknüpfung zwischen der E-Mail-Adresse und der neuen OpenID-URL bestätigen würde. auch

Siehe: openid.sig -- How is it generated?

Answer 3

Es ist eine weitere mögliche Behelfslösung. Wenn Sie die indirekte Authentifizierungsanforderung (Weiterleiten an den Service-URI) senden, senden Sie die alte OpenID-URL als Werte für die Parameter openid.claimed_id und openid.identity, auch wenn Realm auf den neuen Realm festgelegt ist.

Auf meinem Entwicklungscomputer habe ich die Domäne 'thiscomputer' mit 127.0.0.1 aliased. Wenn ich die Authentifizierung von Googles OpenID Provider angefordert, Reich ‚http: // Diesercomputer‘ und openid.identity und openid.claimed_id beide auf http://specs.openid.net/auth/2.0/identifier_select, bekam ich wieder so etwas wie:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

Ich bat dann die Authentifizierung aus dem OP, Reich ‚http : // localhost 'und openid.identity und openid.claimed_id beide auf http://specs.openid.net/auth/2.0/identifier_select gesetzt. Ich habe wieder so etwas wie:

https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ

Ich bat dann die Authentifizierung aus dem OP, Reich ‚http: // localhost‘ und openid.identity und openid.claimed_id beide auf https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ (die OpenID-Identität für mein Google-Konto, wenn Reich ist ‚http ://dieser Computer'). Ich habe zurück:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

Das heißt, ich habe die gleiche OpenID Identität URL zurück, wie wenn Reich ist ‚http: // Diesercomputer‘. Obwohl ich meine OpenID-basierte Web-App von "thiscomputer" auf "localhost" "migriert" habe, kann ich trotzdem die alte OpenID-Identitäts-URL verwenden.

Diese Lösung funktioniert so lange, wie Sie die alte OpenID-Identitäts-URL des Benutzers kennen, möglicherweise weil sie in einem Cookie gespeichert ist.

Eine Anmerkung: Ich habe versucht, openid.identity und openid.claimed_id auf unterschiedliche Werte einstellen (zB ist http://specs.openid.net/auth/2.0/identifier_select, während der andere https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ ist oder man ist https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ und der andere ist https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ), aber die Google-OP-Dienst reagierte mit „Die gewünschte Seite ist ungültig . "