Data Portability

edit topic

Consuming OAuth intelligently in Rails

Published July 21st, 2009 edit replace rm!

It has been fairly easy to provide OAuth services in your web application (see How to turn your Rails Site into an OAuth Provider), but to actually consume Twitter, FireEagle, my own Agree2 and other OAuth services has been a fairly manual affair.

There are great gems out there that wrap up the process for the above mentioned services. So it hasn’t been too hard to support one of them. But what to do if you want to support 5 different services today and more in the future?

I knew there should be some generic approach to handle the OAuth authorization process, but had not spent too much time thinking about it until we actually needed to consume external web services for Agree2.

Well I think I’ve cracked it in a a nice Dont Repeat Yourself fashion.

Major update to Ruby on Rails OAuth Plugin

Published July 21st, 2009 edit replace rm!

I am really happy to announce a major update to the Rails OAuth Plugin it has been coming over the last week or two with help from Nobukazu Matake.

The plugin is now a gem. Just install it with:

sudo gem install oauth-plugin

For a quick tutorial in how to use it see How to turn your rails site into an OAuth Provider.

New OAuth Consumer generator

The biggest news is the OAuth Consumer generator which should remove any excuses you ever had to not use OAuth when talking to Twitter etc. I will cover this in more the next blog post. For now checkout the README for more.

OAuth 1.0a support

The biggest change on the Provider side is support for OAuth 1.0a. There is also optional backwards compatible support for the insecure OAuth 1.0.

Please read Seth’s Idiot’s Guide to OAuth 1.0a for detailed information on what changed and why.

Nothing has changed on the OAuth 1.0a for existing AccessTokens, but if you need to support clients that only support 1.0 add the following at the bottom of your environment.rb file:


HAML support

Both consumer and provider will now create haml view templates. Just use the —haml flag.

Cleanup and easier updates

The original plugin was a really quick proof of concept, with lots of things that really needed cleaning up. I am trying to do that little by little now.

The first step of this is to have the main functionality of the OauthController in a module within the plugin. This allows you to update it easily. We will do the same for the various Token classes as well over the next few releases.

How to upgrade?

As long as you’re using git/svn or whatever the easiest way to upgrade is to run the generator and let it overwrite your existing files. Then use a diff tool to bring any changes you had done into the new code.

If you don’t like the idea of doing that check the README for what should be done. Worst comes to worst create a dummy rails project run the generator and compare files.

Do you need advise or help with implementing OAuth in your Rails application?

I am available as a consultant and would be glad to help your company out. Whether you need help in developing an OAuth strategy or in practical hands on implementation help. Send me an email at [email protected] to let me know what you need help with and I can give you an estimate and my rate.

Openness and the OAuth Legal Dance

Published June 26th, 2008 edit replace rm!

I’m sitting at the OAuth Summit held at Yahoo in Santa Clara. We’ve had a brief discussion about the IPR policy negotiation process that has been going on in the background between a few core OAuth people and legal departments in various large companies (most notably Yahoo, Google and Microsoft).

Briefly the IPR policy allows employees at large companies to collaborate on the standard while promising to not sue anyone who uses their companies Intellectual Property through use of the standard. So basically Yahoo can’t come sue anyone using OAuth for using some patented algorithm they submitted to OAuth.

The IPR policy is important and good work. That said the current second revision of this is essentially a secret document that will be presented signed, sealed and delivered to us b-list members of the community in a week or twos time.

The community created the OAuth Non-Assertion Covenant and Author’s Contribution License which all the original OAuth spec signers have signed with the exception of Yahoo.

Eran told us today that apparently Yahoo stalled the process in their legal department as they needed a more detailed agreement. This is fine and great feedback, however these comments should somehow be made public so we the community also can follow it and make comments.

I realize that most developers don’t want to follow this, however it is important that it is transparent and googlable. I suggest a OAuth-legal group, the same way OpenID does or a continuation of the existing IPR License on Agree2 which does offer comments, versioning and a full transparent audit trail.

One comment I was given was that we should let lawyers talk with lawyers. I have to call bullshit on that. These kinds of things are way too important to be left in the hand of lawyers without any kind of external oversight.

Gabe has been doing a great job representing us (the OAuth community), however there are lots of people with opinion on this who would like to follow it and voice occasional opinions. Those of us who are building businesses around OAuth based services need to feel comfortable that we aren’t going to be screwed by some indecipherable legalese in the future. More important if there are disputes in the future the negotiation trail is key for solving them.

The final comment I heard is that large companies like Yahoo and Microsoft don’t want to make it public that they are negotiating this. I’m sorry that is even greater bullshit, thats pre-cluetrain, pre internet thought.

Get with the program. Yahoo has more to loose by not using OAuth than us in the OAuth community have to loose by them not joining us. I’m sorry if thats the way it’s done, I don’t care. This is not the world of industrial age negotiation in smoke filled private lounges. You guys are all internet companies for god sake.

OAuth is about open transparent simple standards for creating a infrastructure thats open to all of us and not just Google, Yahoo and Microsoft. Any negotiations behind it should be too.

Update July 2nd, 2008 Here is the latest version of the OAuth Non-Assertion Covenant and Author’s Contribution License For OAuth Specification 1.0

A review of FireEagle's OAuth UI

Published March 18th, 2008 edit replace rm!

FireEagle is Yahoo’s great new location web service which was recently launched into beta.

This review will not cover the API. A great little intro for this can be found in Interfacing a Rails App to Fire Eagle by Kamal.

I have previously written tutorial on writing OAuth Clients in Ruby or Turning your Rails site into an OAuth Provider. So I won’t go over any code here.

This is strictly about the user interface of FireEagle OAuth implementation. The FireEagle team Tom, Seth and Rabble have done an excellent job thinking about the UI and how it affects the security and privacy.

Which is great as most of the rest of us involved in OAuth have been worrying more about standards and implementations than usability. In reality Usability is one of those very important things that the security world tends to forget. So let’s learn from FireEagle’s example.

Developing OAuth clients in Ruby

Published February 23rd, 2008 edit replace rm!

On the request of many people here is a quick guide to developing OAuth Consumer Application (Consumer==Client in OAuth Speak) in Ruby.

I will be using Agree2 as the sample application here, so feel free to go Register and load up a irb session to follow along. You could also do the same with Twitter’s OAuth or any other OAuth server.

The general process is:

  1. Register your consumer application with the OAuth compliant service to receive your Consumer Credentials (This is only done once)
  2. You initiate the OAuth Token exchange process for a user by requesting a RequestToken from the Service
  3. You store the RequestToken in your database or in the users session object
  4. You redirect your user to the service providers authorize_url with the RequestToken’s key appended
  5. Your user is asked by the service provider to authorize your RequestToken
  6. Your user clicks yes and is redirected to your CallBack URL
  7. Your callback action exchanges the RequestToken for an AccessToken
  8. Now you can access your users data by performing http requests signed by your consumer credentials and the AccessToken.
  9. ????
  10. PROFIT!!!

Get your Consumer Credentials

Once you are logged in to Agree2 click the Manage OAuth Applications link in the footer:

All OAuth capable applications require you to register your own application first to get your consumer credentials:

Click Register your application

Enter the name of your application, the url of your application, the callback url and an optional support url.

The callback url is the url that Agree2 redirects to after a user has authorized a token for you. For now just enter a url like Click register and hey presto:

These are your applications Consumer Credentials.

Hooking up your code

As we are nice guys here at Agree2 also provides actual sample Ruby code on the credentials screen. I will go through this step by step.

First of all you need to install the oauth gem (make sure you have at least 0.2.2):

sudo gem install oauth

Your code needs to require the gem and the consumer part of the library:

gem 'oauth'
require 'oauth/consumer'

Instantiate your Consumer object with your credentials: "AVff2raXvhMUxFnif06g", 

Now request a token from Agree2. This method actually performs a signed http request to :

@[email protected]_request_token

Now you need to redirect the user to the authorize_url

If you’re in irb just output the url:


In a real rails application you would perform a redirect:

redirect_to @request_token.authorize_url

The user will be taken to this screen to authorize the token:

I think we need to work a bit on the user interface for this. But it does work. The user authorizes the token. and the user is redirected to the callback url you specified earlier.

In your callback action you now need to exchange the request token for an AccessToken:

@[email protected]_token.get_access_token

Now you are ready to do whatever you wanted to do:

# Request all your users agreements
@[email protected]_token.get "/agreements.xml"

The access token object has all the normal http request methods and returns a standard ruby http response.

Our next step is to integrate this with ActiveResource. This is being worked on now. Once this is done I will update this tutorial.

If your company needs help getting your OAuth Strategy right or implementing OAuth in your application I’m available for consulting work [email protected].

Join my Blockchain newsletter

Receive all my latest articles on Bitcoin, Ethereum and building businesses using Blockchain technologies.

I will never send you spam. Unsubscribe at any time.

About me

Pelle gravatar 160

My name is Pelle Braendgaard. Pronounce it like Pelé the footballer (no relation). I live in wonderful Managua, Nicaragua. I work with Clojure, Bitcoin and Ethereum.

More about me:

Other under Data Portability

Popular articles