Ok, I admit this post is for geeks but even geeks can’t keep up with all the latest technology all the time, so I guess I am ungeeking OAuth (pronounced “Oh Auth” and short for Open Authorization) for geeks, wait, is that like oxymoron?
If you have accounts on multiple social sites like youtube, facebook, myspace, flickr, etc, you have probably been asked by at least one if not all of the sites to invite your friends during signup and probably repeatedly afterwards. Usually this involves handing over your private username and password to your favorite email accounts like Yahoo, Gmail, etc. By handing over your private information, you allow the site(s) to scrape your email contacts for their emails so the site(s) can spam them with invites, lovely huh. In the back of my mind, I always have this discomfort about what the site(s) might do with my private login information, it’s like giving someone the keys to your house and hope that they don’t make a copy and raid your house later on.
I extracted most of the 2 paragraphs below from the OAuth About page.
Obviously sharing the same discomfort as me, a few open source developers got together and studied several existing proprietary authentication implementations (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). Each protocol provides a proprietary method for exchanging user credentials for an access token or ticker. Out comes OAuth based on the best practices and common functionality of the proprietary implementations.
So what is OAuth? OAuth allows the you the User to grant access to your private resources on one site (which is called the Service Provider), to another site (called Consumer Application, not to be confused with you, the User). This isn’t the same as OpenID. While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts).
OAuth Process Flow
I extracted most of the following from an excellent post Developing OAuth clients in Ruby.
To better understand things, let’s look at the process flow – you probably need to be a developer to make sense of it.
- Register your consumer application with the OAuth compliant service provider to receive your Consumer Credentials (This is only done once)
- You initiate the OAuth Token exchange process for a user by requesting a RequestToken from the Service
- You store the RequestToken in your database or in the users session object
- You redirect your user to the service providers authorize_url with the RequestToken’s key appended
- Your user is asked by the service provider to authorize your RequestToken
- Your user clicks yes and is redirected to your CallBack URL
- Your callback action exchanges the RequestToken for an AccessToken
- Now you can access your users data by performing http requests signed by your consumer credentials and the AccessToken.
If you want more details (especially if you are a Ruby on Rails guy), check out the post Developing OAuth clients in Ruby.