There has been a lot of discussion lately around Twitter's use of OAuth. I had added a post around earlier around the countdown to OAuth. Now that the Twitter apps are forced to use OAuth, new issues and complains are popping up.
A post by Ryan Paul has attracted a lot of attention in his recent post around OAuth.
A lot of issues that he mentions could be attributed to Twitter's implementation of OAuth rather than generic OAuth itself. However one core issue that he brings up is around suitability of OAuth for desktop applications. The OAuth version 1.0a happens to be the latest version of the specification. I was under impression that OAuth 1.0a was meant to be used for web applications only. This is because the specification in general is pretty vague around use with desktop apps. However when I checked again, it does say clearly mentions this upfront: "OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications." desktop applications? Really?? I just think it is an overstatement to claim that OAuth is suitable for desktop oe mobile apps. Let's look at why it is not make it ideal to use for native app.
Credential Management Issues:
The API caller needs to identify itself by specifying who I am. That who I am is basically its OAuth credential (combination of consumer key and consumer secret). So in this case, this desktop and mobile app will need to have its own credentials that it needs to use. This credential management poses a couple of interesting challenges.
First, how does app gets its credentials? Is this something that app is shipped with? If so, would the same credentials be shared by every application that is installed? Once you start thinking about this process, you will realize that distribution and management of the credentials is a nasty problem.
Second aspect is around securing these credentials. This secret will be installed with the application. How can we ensure that these credentials would be secured inside the app? What kind of encryption/decryption would be used to keep the credentials. As Ryan Paul pointed out in his post, he could crack the OAuth credentials of the Twitter sample program itself :-(
The issues mentioned above pose less of an issue in server environment. The credentials are secured on the server typically at one place inside the server app. The users typically do not have any access to the installation.
Request Token Authorization Issue:
As part of the OAuth flow, user needs to authorize the access to his/her content. It is achieved by sending verifier code for request token. The OAuth 1.0a specification allows using out-of-band (oob) way where verifier code is handed to the user rather than as a part of browser redirect. However this is not ideal. This is because, the user is then supposed to key in the verifier back in the app. Various ways have been invented to work around this step. However none of them very user friendly. Earlier this year I read around half of the OAuth flows that are initiated on iPhone are never completed.
So, in summary, as I elaborated here any attempt to force OAuth for desktop apps is problematic. Google Buzz and Facebook have both tried to solve this issue in their own way outside OAuth 1.0a specification. Some of this is coming together in OAuth 2.0 draft in the form of different profiles. However it is still something we need to watch and wait for!
