Recently Twitter updated their API Wiki with a new “Sign in with Twitter” page that explains OAuth in more detail and provides several “Sign in” buttons. This created a big buzz with ReadWriteWeb, TechCrunch, Mashable, and others all calling it a new entrant in the portable ID sector (OpenID, Facebook Connect, Google Friend Connect, etc.). I called BS on this as I saw the authors were premature in their predictions (plus all commenters on these stories).
One author, whom I highly respect, contacted me directly asking what my take on the story was. Here is my response (with slight modifications):
Not sure of your technical level, but I’m going to breeze through this.
There are two fundamental open source credential mechanisms – OpenID and OAuth. Most “single sign on” is based on OpenID or a variant (both Google and Facebook are embracing and extending here). The problem with OpenID is that it is http based and actually requires you to visit the issuing site to supply your credentials. This won’t work for every case, such as mobile apps or basically any non-web app. This is what I refer to as the OpenID dilemma.
With OAuth, the login process is decoupled further. So if you are on a mobile app and attempt to sign in with twitter, the app will tell you to visit twitter.com to complete the process. You visit twitter.com and are presented with a dialogue saying “so and so app is requesting authorization”. At that point you approve or deny. Once approved, the mobile app forever more has the ability to access your twitter account. As far as I know, the first large adopter of this is Flickr. It is sort of ironic that Twitter actually began the OAuth efforts years ago.
In the twitter API, the OAuth calls have been available ever since I started developing my own twitter tools. So I always wondered why OAuth was never forced on third party developers (I think this was just a smart business decision). So now we have thousands of third party twitter apps that request your username/password for use and you have no idea how reliable the apps are or the people behind them.
In an effort to increase OAuth usage, twitter added the “sign in with twitter” buttons (and also gave the OAuth calls more prominent placement on the main API page). There really isn’t anything new here except a few graphics and twitter providing a little more documentation on OAuth. You can see an example of how it actually works at twittermass.com.
So the bottom line is OpenID is used more often as a “single sign on” and OAuth is used as a security measure for API calls. This doesn’t mean OAuth CAN’T be used as for “single sign on”, but I highly doubt that it will.
Twitter is being extremely cautious with their model right now so throwing down the gauntlet of a new “single sign on” really doesn’t make sense. I have no inside information, so I could be totally wrong here.
If you have any insights on this, I would love to hear them.