Using mod_oauth_openid with Google Apps

Because of a recent release on a Jenkins plugin for Google Apps SSO, I wondered whether there was a way to get mod_oauth_openid without prompting a user to choose between Google Apps domains.  The basic approach would have been to set Apache configurations similar to the one described in this previous blog posting except for the following lines:

AuthOpenIDTrusted ^

If you try to make mod_oauth_openid work with the configuration above, chances are you’ll see “OP is not authorized to make an assertion regarding the identity”.  This issue was encountered by another user in this thread (the Step2 libraries referred are the OpenID Google App discovery extensions that Google refers at  Unless a patch is made to mod_auth_openid or the underlying libokele C++ library to support these Google discovery extensions, chances are that you won’t be able to use this approach.

The apparent problem is that Google has a special way of dealing with OpenID discovery process:

It is important to note that the RP must use a slightly different discovery mechanism to support Google Apps accounts, which is covered in depth here. In short, during the OpenID discovery process, RPs must check both (using as theexample domain) and for discovery information, as the site owners may opt to have Google host this information, rather than host it themselves.

Basically it means that that when a user authenticates on Google Apps, you’re given back not only a unique identifier for the user (known as the claimed id), along with a URL. If your domain is, the URL that is returned is<id>. In OpenID specs, this URL is expected to be available for you to grab metadata to determine where to inquire about this ID.  If an OpenID library tries to open this URL, chances are that it will 404 and therefore fail the user discovery process.

Google proposes that the users implementing Google Apps SSO look both at or Neither of these URLs follow the OpenID spec since one of them requires you to host this metadata, but you also have to deal with digitally signing it too). The approach is summarized in the User Discovery section of the Google OpenID documentation.

The Jenkins OpenID and Python OpenID plugins skip this step and just assumes is the correct URL to use.  Normally the metadata would need to include this <URITemplate> tag, which then gets used to perform the user verification.

More background here: 

Also, someone else attempted to side-step this issue with Google Apps and mod_auth_openid, but it feels more of a way to circumvent some of the OpenID discovery process:

Difference between max-age and expires cookies

  • Expires sets an expiry date for when a cookie gets deleted
  • Max-age sets the time in seconds for when a cookie will be deleted
  • Internet Explorer (ie6, ie7, and ie8) does not support “max-age”, while (mostly) all browsers support expires

Any cookies that you create with the httponly attribute will not be present in JavaScript’s document.cookievariable on browsers where HttpOnly is supported. Browsers will still send HttpOnly cookies when making AJAX calls or XMLHttpRequest calls, however their values still cannot be accessed from your JavaScript code.