- Scott Fleckenstein a developer at GetSatisfaction.com gave a talk on the "How of OAuth" at the Web 2.0 Expo.
OAuth is a community-developed, open Authorization protocol that is part of the Data Portability initiative.
For those who haven't geeked out enough at the Web 2.0 Expo there is an OAuth Hackathon going on at the SixApart offices. (Details at http://icanhaz.com/oauth)
Scott started off as a sceptic. During development of GetSatisfaction he came across a use case that fitted OAuth to a "T".
For those that don't know about OAuth. Here is the high level view....
OAuth allows website X to access your protected data via an API at website Y. OAuth does this without sharing your password. OAuth grew out of the need to integrate applications around Twitter.
In technical terms OAuth gives you:
- Signed HTTP requests
- Safe, password-less token exchange
Libraries are available to do the generation of tokens that are attached requests.
There are three parties:
- User
- Application
- Consumer
There are three tokens to circulate:
- Access tokens
- Request tokens
- Consumer keys
This leads to three urls:
- Request Token Issuer
- Authorization Page
- Access Token Exchanger
Once you have created an OAuth framework then the above URLs can be repeated for other services. ie. Build once and use many times. The URLs are not specified in the specifications. This is a benefit because it makes the protocol completely cross platform.
Libraries exist for many languages to generate low level code and signatures for OAuth.
Creating a Consumer - The steps:
- Get a consumer key from the service provider you want to interface with
- Generate a request token
- Authorize the request token
- Exchange a request token for an access token
- keep the token attached to the user's record. Remember that the user has control. The user is in control because they can revoke access from the other side of the link if they want to.
- Make Authenticated calls to the service.
Building a Service Provider - The steps:
Implementing a Service Provider is easier than implementing the consumer side, however there may be more data to store as a result of this process.
- Consumer - key, secret and callback url
- Request token - Token, secret, consumer and authorizing user
- Access token - token, secret, consumer, user
Registering Consumers:
As a service provider you have to decide how to issue instructions for registering applications.
Getting security right is tough to do. Therefore use the libraries to accomplish this tricky work.
For example, MySpace's API uses the OAuth API to sign the HTTP requests when using their API.
The Consumer secret doesn't have to be kept secret. So, if Javascript or cookies are used to retain the information it is still of no use without the Resource and Access tokens.
SSL really only needs to be used around the Consumer Key because http requests include the signed key and a single use number that avoids
For examples of OAuth in real life check out:
- Pownce
- Any Flickr application
OAuth Discovery is an implementation of XRDS. An XML based format for discovery of OAuth compliant services. This is a brand new spec.
Role-based security is left to the consuming application.
