Tuesday, June 8, 2010

Twitter's Countdown to OAuth



OAuth 1.0 has been around for some time now. The adoption of OAuth has grown tremendously in last couple of years. The standard is evolving and there is significant interest in OAuth 2.0.

While companies are enthusiastically embracing OAuth, they are yet to dump their existing api authorization framework (example: salesforce.com). One can argue that drastic change like discontinuing support for non-OAuth based auth framework will impact hundreds (or thousands) of third party apps and might hurt the company. It is interesting though to understand what Twitter has announced. Twitter is doing courageous thing by publicaly announcing they are dumping BasicAuth in favor of OAuth. In other words, if you are to call Twitter APIs, you must use OAuth. The efforts needs to be appreciated. This is coming from a company which receives 75% of requests in the form APIs.

So, what really prompted Twitter to make that switch?

First of all, one can see that it is probably in Twitter's DNA to do the things right way. Twitter has a prime example of a company that is using Open Standards the way they are to be used. This has been obvious the way they did 'Sign in With Twitter' via OAuth rather than proprietary methods employed by Facebook in 'Facebook Connect'.

Now, let's dive into some technical aspects. In BasicAuth, user's credentials need to be sent with the API calls and it makes itself vulnerable to Man-in-the-Middle attacks. While this can be addressed by using SSL (secure transport layer), unless you do it right, it is problematic.

The next issue is around password management. Using BasicAuth means the API caller is forced to send the user's userid and password. That means users do need to share their passwords with API caller (external app). How many of us use the same password for multiple site? Would you be willing to share your password with third party app that you are not much familiar with? What happens if the api caller's website is breached? When you change your password, what happens to integration?....Once you start thinking on those lines, you will quickly realize that it is always problematic to share the passwords and trust different parties to manage the secrets. These slew of problems simply go away with OAuth.

Finally.. the service providers get enormous flexibility and traceability with OAuth. They can associate each API call to not only user who is making the call but also to each third party app that is making the call. It helps them to understand and analyze who is making those API calls.

Read more at http://www.countdowntooauth.com

Wednesday, June 2, 2010

There is an API for that !



Open APIs are exploding in numbers. Recently RWW published an article discussing the services that are already processing billions of APIs a day. The statistics is simply mind boggling. The top service providers are Google and Facebook. This should not be surprising. What is surprising is that they are getting 5 billion API calls a day ! That is right.. 5 billion calls a day !! Way to go !!!

Another interesting aspect is that for some of the services like Twitter or Salesforce more than half of the requests are submitted via APIs. That tells a lot around the usage model for these services.

For the pure techies.. if you are still wondering how much of this is SOAP vs REST, it turns out REST is popular 4:1 margin. This is hardly a race.

The days of whether we need APIs are gone. The picture below summarizes it the best.







Just like there is an app for that, it would be fair that there is an API for that!