OAuth-ify this: 2 Legged OAuth service for YQL

Introducing OAuth-ify/OAuthProxy, a service that performs two legged OAuth calls to backend webservices. As of today it only supports YQL.

Motivation:

With two-legged OAuth, there are only two parties involved i.e. the consumer of the api and the service provider. It doesn’t deal with user credentials or other private data that come into the picture with three-Legged OAuth. YQL is one of the services which uses OAuth exclusively for all webservice access. (apart from the console)

Two-Legged OAuth requires a user to sign the request in a spec mandated way and this implies that using a service such as Yahoo! Pipes to fetch non private data from YQL wasnt possible.

Requirements:

  1. The service should ask for everything it needs and respond with the result of the backend service. Simply put, the service must act as a proxy. Take in the Consumer Key, Consumer Secret and the YQL query, do the necessary signing and return the response.
  2. What if I do not want to expose my consumer key/secret for the fear of it being compromised? This brings up a requirement that there should be a way to mask the Key and Secret. This is accomplished today by explicit registration. The user is asked to register their Consumer Key and Secret with the service and in return they get an appId which is URI friendly.
  3. AppId should be disposable. If an AppId is compromised, it should be possible to regenerate a new one which inturn uses the same underlying key/secret pair. (Note that I still want the underlying Consumer Key and Secret to be the same for many track-ability reasons and relationship with the service provider)

Implementation:

I deployed on Google App Engine (for lack of a platform that runs Java on the cloud!) and picked up a bit of python along the way. I must say that GAE’s been pretty easy to pick up and use. Finally the service exposes two main endpoints

  • Executes a query given the following parameters (http://oauthify.appspot.com/yqlQuery)
    • Scenario 1: http://oauthify.appspot.com/yqlQuery?ckey=aghvYXV0aGlmeXIOCxIIVXNlcklhZm8YBgw&csecret=PQ&q=show%20tables
      • ckey - Consumer Key (required)
      • csecret - Consumer Secret (required)
      • q - YQL Query (defaults to show tables)
      • format - xml or json (passed to the backend) (defaults to XML)
    • Scenario 2: http://oauthify.appspot.com/yqlQuery?appId=aghvYXV0aGlmeXIOCxIIVXNlcklhZm8YBgw&q=show%20tables
      • appId - App Id provided by the service. (Also see the next endpoint)
      • q - YQL Query
      • format - (same as above)
      • Note that the prequel to this Scenario is that the user gets the appId by registration.
  • Register the Consumer Key and Secret to get an appId (http://oauthify.appspot.com/register)
    • Requires a user to Login (using a google account). This is to protect the user’s Key and Secret.
    • Provides a way to store CK and CS
    • Provides a way to see all previously stored Keys and to regenerate AppIds as needed.

Finally:

Was the Goal of running 2 Legged YQL in Pipes accomplished? Yes! check out http://pipes.yahoo.com/nageshs/yqlquery which uses a PrivateString fields to use CS and CK from Scenario 1 above and last but not the least http://pipes.yahoo.com/nageshs/yqlquerymodule which uses an AppId from the web service. Here is a screen shot of the Pipe. I’m not in the least worried about sharing my AppId, since OAuthify will let me regenerate it any time I like ;-)

Enjoy & Curl your YQL queries today!

Update 1: Thanks to Sam, OAuthify is now accessible via the rightly named domain http://OAuthProxy.com

Share
  • del.icio.us
  • Facebook
  • Digg
  • description

Related Posts

No related posts.

November 9th, 2008 in oauth, yql | tags: , , ,

Viewing 14 Comments

 

Trackbacks

(Trackback URL)

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus