OAuth and Twitter

Recently, I came across this article - Compromising Twitter's OAuth Security System.

At first blush, it looked to me like a frank (objective) look at a technology and issues with its implementation – way different from the flattering, fanning the hype kind of articles we typically come across.

However, it serves to decompose, or strip down the article to its main points (its quite verbose), and see what the conclusions are. The first point (written in couple of pages) is that Twitter's OAuth implementation is bad because it requires client credentials even for desktop/mobile applications (such applications will have to embed the secrets in their binaries). And that since such binaries can be easily reverse-engineered, hackers can get to such secrets easily. Fair enough. The article does note that Twitter did offer some alternatives - like per instance registration, or having a user specific component for the key. However, such alternatives are shot down in the article as either inconveniencing the user, or not actually implemented by Twitter. FOSS has been made a focal point of the argument as the source code is open, thus the keys are going to be necessarily open.

OK...fair points all. But what are the alternatives? One suggested one is 'remove any client authentication for such applications'. Wow! This is where I so much differ. (Kind of like - what did you just say?) To quote from the article - "If Twitter does the right thing and eliminates the requirement for desktop applications to use secret keys, it would effectively resolve the problem for FOSS clients." Apparently, Google and Facebook, according to the article, have come up with “reasonable solutions” - to quote from the article "... that do not require a secret key or require the end user to go through a complicated copy/paste process". So, is absence of security is what we are after? (Actually, FB comparison is not apples to apples, as FB implementation is based on the draft 2.0 spec.)

However, I do agree with couple of points raised in the first section of the 3rd page - one is to do with the user NOT being logged out of Twitter after the flow completes, and another to do with the misleading interpretation of the 'Deny' action. To me these are important considerations and ones that can be easily fixed.

On the 2nd section of the 3rd page (about phishing risks), though, not sure what others are doing here, but there is an important detail that has been left out. The key here is that the user is on the client app's page before the flow starts. This means that user is aware of the authenticity of the client web site - and even if they are not aware, it is their responsibility to know to whom they are giving authorization. I do not expect (nor does the standard anticipate) Twitter (or any others in that role) to properly vet the client web sites. The protocol allows only that who made the original request is the one that actually gets the authorization. It is up to the end user to verify which client web site they are dealing with. A related technology is EV SSL certificates (which, BTW, have been brought about after decades of public PKI). But EV certs are offered by a much controlled process, and costs money. I do not expect such a process to be put in place for a photo sharing web app.

The article concludes that 1.0a version is "...a horrible solution to a very difficult problem.". I would not use such sharp words. We have to recognize that for any technology to mature, it takes time, and more importantly, no single technology can address all the scenarios. Heck, physicists have been trying to come up with a unifying theory that explains everything in the universe, but so far they could not - meanwhile, we have relativity theory, quantum theory, Newton's theory and so on! I can live with that.