Monday, April 24, 2006

Google SSO, GData and X-GOOGLE-TOKEN

The details of Google's Account Authentication Proxy for Web Applications are not yet available but it looks likely that this is the basis of a Google Single Sign-On (SSO) service. Applications using this service will be able to make use of Google's GData enabled applications (calendar, blogger, mail etc). You would expect that in due course there would be third party server applications interested in supporting the GData protocol.

Google has whetted our appetites with the Google Data API with emphasis on the calendar functionality. I hope they remember the open source mantra, release early, release often and don't make us wait too long before the full disclosure of Google's proxy authentication mechanism (expected release date is the end of this month [April 2006]) and the details of the other GData enabled services. Google have been criticised in some quarters for not contributing enough back to the open source community and this represents an excellent opportunity to make amends.

Having had experience with JASIG CAS I know a little about how single sign-on for web applications work. I discovered a very interesting article detailing The Mysteries of X-GOOGLE-TOKEN and why it matters which describes a curious proprietary token-based authentication mechanism that Google Talk uses. It appears to behave exactly as I would expect Google's SSO proxy mechanism to work. It seems like Google SSO may have been in in the wild all along and we just haven't realised it!

I think it is a fairly safe bet that X-GOOGLE-TOKEN will emerge in the proxy authentication part of the GData protocol.

There are some suggestive indications of how the proxy mechanism will work in the GData API, if for example you look at one of the constructors for GoogleService:

GoogleService(java.lang.String serviceName, java.lang.String applicationName, java.lang.String protocol, java.lang.String domainName)
Constructs a GoogleService instance connecting to the service with name serviceName for an application with the name applicationName.

I would expect that I could create a GoogleService instance with my local applicationName and domainName as arguments. This could authenticate against Google's SSO and call my local application back following authentication. Google SSO would send back the details necessary to validate authentication and conduct further proxied authentication making use of the X-GOOGLE-TOKEN, SID and LSID tokens mentioned in the Google Talk article.

Note also how the GData API constant GOOGLE_LOGIN_PATH of /accounts/ClientLogin is exactly the same URL as Google Talk uses for authentication.

Although I feel that there are now lots of clues, my feeling is there are still some missing pieces of the jigsaw. An anonymous source suggested that they thought that the X-GOOGLE-TOKEN mechanism might be enabled via "a piece of copypaste JS code". I would agree with this idea to some extent, however, we now know that the favoured GData client mechanisms are Java and C#. Therefore I would speculate that much like the Google Maps API requires a key, the Google Proxy Authentication Service would make similar demands on would-be SSO application clients.

0 comments: