« Sparql Clipboard | Main | Let the loose coupling take place in the cloud »
29 June 2006
Web Application Authentication
Posted by Ian Davis at June 29, 2006 01:31 PM
Google just launched their Account Authentication mechanism:
Google Accounts authentication for web-based applications allows the application to access a Google service protected by a user's Google account. To maintain a high level of security, the Authentication Proxy interface, AuthSub, enables the application to get an authentication token without ever handling the user's account login information. Using the proxy, the user of the web application logs into their account through a Google-supplied login page and consents to grant limited access to the web application.
This comes while a post from Dare Obasanjo was fresh in my mind:
The devil is in the details when talking about authentication, authorization and Web APIs. When I first heard about the Yahoo's proposed authentication model for Web APIs at their ETech 2006 talk entitled Building a Participation Platform: Yahoo! Web Services Past, Present, and Future, I thought it sounded similar to the model used by
PassportWindows Live ID. In both approaches instead of applications prompting users for their credentials (username/password combo), the user signs in to the primary service which then returns an opaque token to the target application that identifies the user and gives the application permission to access the user's data. However, having a fine grained access that can give applications access only specific services and can revoke permission given to specific applications seems to be richer than what I've seen offered byPassportWindows Live ID. This is nice but it's to be seen how easy this will be for users to understand or for applications to manage.
Dare then goes on to define two characteristics of web application authentication that he sees as essential:
User credentials are sacred and must be protected at all costs: A security mechanism is only as strong as its weakest link. This means that it is extremely unwise to build an authentication model that has applications built on your APIs to request username/passwords or other credentials from users directly
and
Do not discriminate against any platform or any device: In todays world, end users interact with online services using a variety of devices and platforms. Each device and platform has different strengths and limitations but is important in its own right.
As far as I can tell, Google's authentication appears to satisfy both points, provided you read Dare's words as meaning "don't discriminate so long as the platform or device can speak HTTP". The Google approach is almost identical to the established Flickr authentication API, the only functional difference being that Flickr returns the login page and consent form in two steps rather than Google's single step. Google also supports secure access using certificates which is a welcome addition.
The Google site includes this diagram of the interactions which at first glance would suggest that the web application somehow asks the Google service to contact the user directly, which of course is unlikely in the web architecture:
I drew my own diagram of the interactions taking place which I think clarifies the situation. The web application redirects the user to Google's service, passing along the URI that it wants Google to send the user back to once they've been authenticated. In this final redirection of the user's request Google includes a one-off token which the application can use to get a longer duration session key for use with other Google services. This is exactly the same model as Flickr's, who call the initial token a "frob".
I'm following development in this space very closely and I'm very encouraged to see two almost identical authentication procedures adopted by these companies. All we need now is a third and we've probably got enough for a de-facto standard, which with a bit of will and wrangling could become a nice little IETF draft.
Update: in the time I spent thinking about and writing this post Google appear to have pulled the API completely. Hopefully it'll return shortly.
Technorati Tags: google, authentication, flickr
Trackback Pings
TrackBack URL for this entry:
http://blogs.talis.com/mt/mt-tb.r280.cgi/442
