Overview of Google authentication methods

There are a number of different authentication methods available for integrating with Google Apps.  These include OpenID, OAuth and SAML amongst others.  At a first glance, it's not always entirely clear on the differences between them and when you may wish to use one over another.  Here's a brief overview which hopefully makes this a bit clearer.

OpenID

OpenID allows users to log into supporting websites with an existing account without ever needing to create a new account. All you need to do is to create an OpenID for your username and password. In fact, the chances are you have one already. Sites such as Google, Yahoo!, Flickr and LiveJournal are OpenID providers, so if you have an account with any of these (or another OpenID provider), then you just need to find out your OpenID. It is usually formatted like a URL, for example, for LiveJournal it is username.livejournal.com whereas for MySpace it's www.myspace.com/username. Just replace username with your actual username. You can then click on the OpenID login link on the site you wish to log in and enter in your OpenID. You don't even need to create an account on the site.

For Google Apps, the situation is the same. The user can log into your Drupal site by entering in their Google Apps OpenID url. If the user isn't already logged into their Google Apps account, they'll be prompted for their login details. Users may also have to confirm or reject a set of authentication requests made by the web application before being redirected back to the Drupal site. The user will now be logged into both sites, but the user's Google Apps account can't be accessed by the Drupal site.

OpenID has been part of Drupal core since version 6. For earlier versions of Drupal, there is a contributed module which provides this functionality at http://drupal.org/project/openid These modules only provide client support, to become an OpenID provider (aka server), you will need the OpenID Provider or OpenID Attribute Exchange modules.

Note, while earlier versions of Drupal's OpenID module supported regular Google OpenIDs, those for Google Apps didn't work due to unsupported characters in the url. This was recently fixed in http://drupal.org/node/216101 so ensure you are running Drupal 6.15 or later to avail of this fix.

Useful links:

• OpenID homepage : http://openid.net
• OpenID 2.0 specification: http://openid.net/specs/openid-authentication-2_0.html
• OpenID Federated Login Service for Google Apps : http://code.google.com/apis/apps/sso/openid_reference_implementation.html
• OpenID Explained : http://openidexplained.com/

OpenID + OAuth (aka hybrid)

This is essentially the same as OpenID, except an Auth Token is also returned to the Drupal site. This token allows the site to access the user's Google Apps account and pull down information, such as their calendar feed. See the next section for more information on OAuth.

OAuth

Google also supports the OAuth standard for API authentication. When not being used with OpenID, the user logs into the site with their Drupal username and password. Once authenticated, they are then immediately redirected to the Google login page where they must confirm (or reject) that the website is allowed to use an authorization token to access their Google account. If confirmed, the user is redirected back to Drupal site, along with an auth token, which the site can then use to access Google data feeds, such as the user's calendars, mails, etc.

If you want the user to be logged into both Drupal and Google, and you want the site to be able to access the user's Google account, then this is a good solution. The only caveat is that it is a two step login - once on the Drupal site, and then on Google. If you just want one login but the same functionality, then you probably want a combination of SAML and 2-legged OAuth.

There are two Drupal modules which provide OAuth functionality. The first is OAuth which integrates with Drupal's Services module. The other is OAuth Common which is a more generic, API module. I found the OAuth module too closely intertwined with the Services module to be of any use for integrating with Google.

Useful links:

• OAuth homepage : http://oauth.net/
• Google OAuth documentation : http://code.google.com/apis/accounts/docs/OAuth.html
• Google Auth (gauth) module : http://drupal.org/project/gauth
• OAuth Common module : http://drupal.org/project/oauth_common
• OAuth module : http://drupal.org/project/oauth

2-legged OAuth

Administrators of Google Apps Premier and Education editions can also use a special type of OAuth, called 2-legged OAuth. Unlike standard OAuth (also called 3-legged OAuth), 2-legged OAuth does not require an authorisation token for the user's account to be accessed. Instead the credentials for a Google Apps administrator are stored on the site. Then for each user, we just need their Google Apps email address. We don't even need their password. The site uses the administrator's credentials to authenticate with Google. Unlike standard OAuth, the user is not actually authenticated with Google, but the site is able to act on their behalf to pull in or update their account data.

Useful links:

• 2-legged OAuth documentation : http://code.google.com/apis/accounts/docs/OAuth.html
• Google Auth (gauth) module : http://drupal.org/project/gauth

AuthSub

Like OAuth, AuthSub is a proxy authentication service. The end user experience is pretty much the same as with OAuth, so I won't go into too much detail here. It was developed by Google, before the OAuth standard was released, and OAuth is now the preferred solution. The Google Authentication module, google_auth (note underscore), provides AuthSub authentication and is available for Drupal 6.

Useful links:

• Google AuthSub documentation : http://code.google.com/apis/accounts/docs/AuthSub.html
• Differences between OAuth and AuthSub : http://code.google.com/apis/gdata/articles/oauth.html
• Google Authentication module : http://drupal.org/project/google_auth

ClientLogin

An alternative to OAuth and AuthSub is the ClientLogin authentication method. It is the only authentication method which works with Google's Provisioning API which can be used to create and edit accounts, and other account operations. For web applications, OAuth is recommended over ClientLogin as it's not as secure. This is because the user's Google Apps credentials need to be stored in the application.

Useful links:

• Google ClientLogin documentation : http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

SAML

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorisation data. This allows users to log into Google Apps directly, but authentication is done against the Drupal database. It's best described by the following two scenarios:

Scenario 1: user logs into Drupal first:

1. user goes to the Drupal site
2. user enters Drupal credentials
3. user not logged into Google Apps
4. user goes to Google Apps site
5. Google Apps redirects to Drupal site for authentication, but as user already logged in this step should be invisible
6. user redirected back to Google Apps and can access their account info.

Scenario 2: user logs into Google Apps first:

1. user goes to the Google Apps site
2. user redirected to Drupal site where they enter their credentials
3. user redirected back to Google Apps and can access their account info.
4. user decides to go to Drupal site, but should be already logged in.

Unlike OpenID and OAuth, the user isn't authenticated in Google Apps until they actually try to access it.

When user goes to Google Apps they will be redirected to Drupal site and will have to enter their Drupal username and password. This solution doesn't allow for Google Apps data to be accessed by the Drupal site, for either display or modification. It also doesn't allow anyone to log into Google Apps with their Google Apps credentials - they have to an account on your Drupal site. This means the user's calendars, etc can not be pulled in via an API call. For this you'll probably need to combine SAML with 2-legged OAuth. This combination allows you to use the API, have the user logged into both sites and still have just one login step.

The Drupal googleauth module (note: no underscore) implements the SAML solution and requires xmlsec to be installed on the server. However, there's no Drupal 6 version for it yet but there is a patch in the issue queue.

Useful links:

• Google SAML documentation : http://code.google.com/apis/apps/sso/saml_reference_implementation.html
• Google Auth module : http://drupal.org/project/googleauth

Shibboleth

Shibboleth is standards-based, open source middleware software which provides web single sign-on across or within organisational boundaries. It is very similar to SAML, so I won't go into much detail in here. In fact, version 2 of Shibboleth also supports SAML 2.0. More information can be found at http://code.google.com/apis/apps/articles/shibboleth2.0.html

Useful links:

• Google Shibboleth documentation : http://code.google.com/apis/apps/articles/shibboleth2.0.html
• Shibboleth homepage : http://shibboleth.internet2.edu/
• Shibboleth module : http://drupal.org/project/shib_auth