Blogj!

I spent most of last weekend trying to get Oauth to work with with a javascript application. I learned a lot about what oauth is, why it is ‘potentially helpful,’ and, most importantly, when not to use it.

Oauth is required by a number of popular web platforms in order to interact with their API. I was trying to use the Twitter API which requires oauth authentication before Twitter will share or accept any information. Ruby makes it really simple to setup this authentication using a gem but since I had a single page javascript site I tried to set up oauth authentication with an ajax call. This was a mistake which I will explain in more depth later.

What is OAuth?
Let’s take a step back and try to understand what Oauth is and why so many APIs require it. Twitter defines it like this, “OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password.” OAuth creates a way for users to grant third-party access to their resources without the need to share their passwords. It also provides a way to grant access in a more limited way like duration and scope.

Think of oauth as a fancy way to authenticate. It allows one service to gain access to a user’s restricted content from another service without needing to receive the user’s username or password from the original service. For example, what if you want catfinder.com to automatically post to your Twitter account every time a new cat shows up in your neighborhood. Catfinder will go through Twitter to ask you (the user) permission to be allowed to post to your twitter account.

Today there are lots of different cloud services with various logins like Facebook, Gmail, and Twitter . Asking users to have unique password for every single service will actually reduce the level of security since people will just start using very simple password like 1,2,3,4 or the same password. It’s simpler if a user can have a unique username and password with Twitter. Oauth lets a user leverage the username and password they have to gain access to other services.

Here’s the basic user flow that a user sees:

1. The user wants catfinder.com to automatically post to their twitter account. Catfinder says, let me go ask twitter.
2. Catfinder reaches out to twitter to ask permission. Twitter gives out a request token and a secret (cryptic string). The secret is used by the user to verify they are coming from Catfinder.
3. The user is redirected to the Twitter to approve Catfinder.
4. The user gives permission to Twitter to let Catfinder post on the user's feed.
5. Catfinder requests an access token from Twitter. Twitter responds with an access token.
6. Catfinder posts to the users twitter.

Here’s the benefits, our hero (the user) never had to share their login credentials with Catfinder all he did was delegate access using Oauth. The user can login into Twitter and revoke permission from Catfinder any time he’s no longer wants pictures of cats in his twitter feed.

Why did OAuth ruin my weekend?
Twitter no longer allows user to request data without setting up oauth. This can be easily handled with a ruby gem or a wrapper if you are using node.js but if you are not using a backend and just writing vanilla javascritp it is extremely difficult. Why is it so difficult? The reason is that its very hard to make key and token strings hidden without a backend. A visitor to your site can find a way to see them.

When you decide you want to access Twitter’s API they will give you the following information that you will need to include as part of your API’s authentication.

• Consumer Key
• Consumer Secret
• Request Token URL
• Authorize URL
• Access Token URL

Handing these off in the correct method and order can be difficult but are nicely abstracted out in a number of different gems, wrappers and packages. Twitter provides a list of libraries: https://dev.twitter.com/overview/api/twitter-libraries