Google's OpenID identifier is different depending on the "consumer" domain name. How to avoid problems if domain name needs to change?

Question

I'm currently testing an OpenID implementation, and I'm noticing that Google sends a different identifier for different consuming host name / domain name, even for the same user. For example, Google sends a different identifier when the requesting site is localhost, compared to the identifier they send when the requesting site is 127.0.0.1 for the same user.

Note: I haven't actually tested this using public domain names, but I can't see why the behavior would be any different.

My concern with Google's behavior is that if we ever choose to change our website domain name in the future, then users will no longer be able to log in to the website using Google's OpenId as the identity provider. This seems to be a big problem. Am I missing something, or are all OpenID consuming sites faced with this potential problem?

I've also tested this with MyOpenId, but the identifier that MyOpenId creates is fixed, so this wouldn't be a problem with them.

Answer 1

Have a look at Google OpenID most important technical issue. Some infos there. Basically a link taken from the accounts section of stackoverflow.com ;)

-sa

Answer 2

It appears that the OpenID URLs returned by Google depend on the openid.realm value that is used. Also, I just tried the OpenID process with a realm set to http://MYREALM and openid.return_to set to http://localhost/openid.php, but received an HTTP 400 Bad Request. Apparently, Google checks that the realm has the same domain (and probably port) as the "return to" URL.

One idea for a work-around is to store the Gmail address associated with the OpenID. Whenever you request a Google OpenID, always request the user's email address via Attribute Exchange's http://axschema.org/contact/email type. If you ever change domains, you can associate the new OpenID URL with their account based on the email address.

Note: It is imperative that you verify the HMAC-SHA1 signature. Otherwise, anyone would be able to "return to" your web application's OpenID checkauth action with a constructed email address, allowing them to take over someone's account if they know the target's Gmail address.

When a user is logging in with their Google Account for the first time after the switch, the migration procedure is:

1. Send a POST request to https://www.google.com/accounts/o8/ud with the following parameters:

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

   (replace openid.realm=http://NEWREALM as appropriate)

   The response will be something like:

    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. With the redirect to the Service URI, https://www.google.com/accounts/o8/ud, mode 'checkid_setup', make sure to send the assoc_handle that was previously obtained as well as require the user's email address via Attribute Exchange. In other words, be sure to send the following, additional parameters:

    +----------------------+----------------------------------------------------------+
    | 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                                                    |
    +----------------------+----------------------------------------------------------+
    

   The "return to" request will include the important parameters openid_signed, openid_sig, and openid_ext1_value_email.

3. Follow the OpenID Authentication 2.0 Specification's procedure for generating the signature. If the base64-encoding of the HMAC-SHA1 signature is not the same as the openid_sig value, then the signature is invalid. Note that the MAC key in this example is F5XUXvoYutLvFv4IzJS0diytLmbe. Use whatever Google's server sent back with the association request.

 

Google's Federated Login documentation page states that http://axschema.org/contact/email "[r]equests the user's gmail address". Presumably, once a Google Account is created then the "Gmail" email address is fixed. But, if this assumption is not valid, then it is not safe to use this procedure because a malicious user could change their email address as returned by the Federated Login Service to whatever the email address is of the account that they wish to steal.

Just to be on the safe side, before activating the new OpenID, send an email verification request to the email address. The verification link would contain a nonce associated with the new OpenID. Once the link is clicked, the new OpenID would be fully associated with the user's account as receipt of the nonce would verify the association between email address and new OpenID URL.

See also: openid.sig -- How is it generated?