Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


June 05, 2008

oAuth: Putting users in control of service-to-service communications

I've been talking about oAuth a lot to colleagues recently; I'd had it vaguely on my radar for a while, but a conversation with David Recordon from SixApart at EduServ last year convinced me to take a more serious interest in the specification. oAuth is essentially a user-centric authorization mechanism for enabling services to talk to each other.

Currently some services enable interoperability by getting the user to delegate authority to the service to interact with another, essentially by enabling it to impersonate the user. For example, you give Flickr your LiveJournal account details so it can cross-post your photos.

With oAuth, the same functionality is enabled without the security, trust and privacy compromises: the user talks to both services and explicitly grants permission for the services to talk, but without revealing any account details.

There are a great many service-to-service contracts that could benefit from this user-centric approach: employers and universities, for example. Or between employers and applicant's portfolio services.

But is oAuth actually being adopted? Well, the evidence suggests it is, with Google announcing adoption, and discussing integration with its OpenSocial and Google Gadgets technology. For Google this replaces its proprietary AuthSub mechanism with one that can be shared across providers.

For eLearning, the oAuth spec is an important building block in developing distributed as well as federated elearning architecture. With oAuth, users can choose to connect together services that have no existing relationships using a common authorization method.

Even better, oAuth is completely agnostic with regard to identity and authentication protocols and models - it doesn't need single sign-on or any kind of shared identity or authentication model between service providers.

The bottom line - if you are developing an application that needs to talk to an external service API on behalf of the user, then you may need to start looking into oAuth.

main archive