Sunday, October 24, 2010

Why use OAuth ? what are the benefits ?


OAuth is open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. In short, it means that a user of your service can provide you limited access to a third party account of theirs. OAuth is often described as a valet key that your users can give you to access their accounts on other services. For example, a user using Flickr (the service provider) would provide Snapfish (the consumer) with read only access to their Flickr account. This lets Snapfish access photos in the user's Flickr account so they can order prints.
It's all in the tokens
How does this happen without asking the user to give up their Flickr password? The flow would start by Snapfish obtaining a 
consumer key and secret and using them to generate an authorization link to Flickr. Once the user follows the authorization link, they are asked to log in on Flickr's site. Once logged in they can choose to grant Snapfish access to their Flickr account. Flickr then marks the request token as having been authorized by the user. Snapfish uses the request token to obtain an access token which can be used by to make requests to Flickr on behalf of the user. This diagram may help visualize it easier. C = Consumer, SP = Service Provider


Generating a valid OAuth request

It turns out that generating an OAuth request is very simple but debugging it is a pain. Every OAuth request contains certain parameters. These include:
  • oauth_consumer_key
  • oauth_token
  • oauth_nonce
  • oauth_timestamp
  • oauth_signature method
  • oauth_version
  • oauth_signature
These can be passed in as GET or POST parameters or in the Authorization header. You'll most likely be passing in other additional parameters based on the API you're accessing. I think it's enough to understand OAuth and why we used it frequently.  More details are available on http://oauth.net/documentation/getting-started 


1 comment:

  1. Summary in 9 lines :P

    1. A user comes to your site.
    2. You show them a nice link saying "Sign up using your Twitter account".
    3. They click on it, and in the background, you send a request for a token to Twitter
    4. You get a request token back.
    5. You send the user to Twitter with this request token.
    6. Twitter shows them a nice page, with the name of the site making the request and what your website wants permission to do.
    7. They click that they agree, so Twitter marks that request token as accepted.
    8. Twitter directs them back to your website
    and takes the request token, and sends a request to Twitter (with the request token) for an "access token". If the swap is successful, your website gets the access token, and knows that that user is legitimate.
    9.You can then create the account based on that information. Or, if the permission you were asking for was to use resources or interact with the Twitter site on the user's behalf, you now can do so.
    10. That's it.

    ReplyDelete