Google Federated Login (hybrid OpenID+OAuth) with wildcard realm

3
votes

I'm trying to implement Google's OpenID+OAuth protocol, and it doesn't work when openid.realm contains a wildcard:

openid.realm: http://*.example.com
openid.ns.oauth = http://specs.openid.net/extensions/oauth/1.0
openid.oauth.consumer = www.example.com
openid.oauth.scope = https://www.googleapis.com/auth/userinfo.profile

The OpenID process works as expected, but the OAuth extension is silently ignored (no request_token in the response; no error either).

As per the documentation this seemed supported:

Use the automated interface to register your domain, keeping in mind that the registered domain must be consistent with the realm parameter being used with OpenID. For example, the domain "www.somedomain.com" is consistent with a realm of "http://*.somedomain.com".

It works with a realm of http://www.example.com (the callback receives a request_token parameter), however I can't change the realm since this would prevent existing users from signing in again.

What am I doing wrong ?

2
oauthopenid
The question is too vague. What is the "it" that doesn't work? What does work? What is the new thing you are trying to do? What domains are registered with Google? How are you signing your requests? – Old Pro
updated: When setting the realm to http://www.example.com and openid.oauth.consumer to www.example.com, the callback receives a request_token as expected. When setting the realm to http://*.example.com and the consumer to either www.example.com or example.com, the callback doesn't receive a request_token (but the openid process succeeds). – Arnaud Le Blanc

2 Answers

0
votes

The consumer must be an actual domain name, not a wildcard. Also, *.example.com specifies a subdomain of example.com; example.com is not consistent with http://*.example.com

The Goggle documentation is unclear, but you may need to register your website with Google in order to use OpenID+OAuth with a wildcard domain. As you can see, JohnS was able to get OpenID+OAuth with a wildcard domain working with out any documented differences from your setup (other than using ex2 instead of ouath as the namespace alias, but that shouldn't matter).

-1
votes

Your Problem is specifically regarding openid.realm with wildcard options:

Authenticated realm.

Identifies the domain that the end user is being asked to trust. (Example: "http://*.myexamplesite.com") This value must be consistent with the domain defined in openid.return_to. If this parameter is not defined, Google will use the URL referenced in openid.return_to.

The value of realm is used on the Google Federated Login page to identify the requesting site to the user. It is also used to determine the value of the persistent user ID returned by Google.

Note: If you've been using both OpenID and OAuth separately, you may be able to use the same domain registration as long as the OpenID realm parameter value matches the OAuth consumer parameter value. If the values don't match, either re-register a domain consistent with the OpenID realm value, or change the value of realm. However, changing the realm may not be a viable option if you have existing users with OpenID.

Another Important thing about OAuth extension:

This is typically a DNS domain name. Must be consistent with the value for realm (for example, realm = example.com and ext2.consumer = "www.example.com", or realm = "http://*.somedomain.com" and ext2.consumer = "www.somedomain.com").