Recent events have pulled Twitter’s authentication methods even further into the limelight. People are becoming increasingly concerned about the safety of their profile and everything associated with it. What’s Twitter going to do about it, and when?

Twitter is working on a beta release of OAuth

Engineer/API Lead Alex Payne commented on the Twitter Development Talk group that the User Experience team is putting the finishing touches on a beta release of an OAuth implementation. This comment was made in November and mentioned a release toward the end of December. Since then, Payne has also said they (Twitter) will be experimenting with it after the first of the year.

The next full release of the API will be by OAuth authentication only

That only makes logical sense, right? After all, you have to eliminate all the weakest links to make a stronger chain. Also, using OAuth will decouple API rights from the general access rights used on the web. In turn, you’ll see more granularity of access control using OAuth, which is something BasicAuth sucks at.

Unintended Consequences of Better Security

For starters, OAuth is much more difficult for third-party developers to implement than BasicAuth is. It’s a new set of tools and technologies that most people aren’t really that familiar with. OAuth also entails bouncing around to the browser while authenticating, much like OpenID does. Once you allow your app once, you should be able to have it remember that and be fine on subsequent authentication attempts. However, it’s going to confuse a ton of people the first time. OAuth is not a security silver bullet, but is a step in the right direction. ( Payne’s words on OAuth )

Our Plea

Twitter: please don’t give up on this. We can’t stand to see it go the way of Track or IM. We desperately need to feel safe when using our credentials as recent events have given you a bit of a black eye. OAuth, OpenID, we don’t care – just make us feel warm and fuzzy inside.

Last week I wrote a post about OpenID on my personal site. There’s another authentication method similar to, but different from, OpenID called OAuth. OAuth stands for Open Authentication and was formed by a committee of users. The original spec for OAuth was released in late 2007. OpenID and OAuth were conceived for the same general purpose, but have little in common.

Imagine you own an expensive luxury car. A night on the town could put you at a fancy restaurant that offers valet service. Instead of giving the valet your owner’s key, you could hand the valet a less privileged key that would only start the car, allow it to be driven for one mile, and also lock out non-essential services (address book, navigation, etc). This is the basic concept of OAuth.

When you pass your username and password to an API, you’re giving it complete access to your account. If the wrong people get a hold of your credentials, they could use it maliciously and potentially lock you out of your account. Giving an API a password that only allows it to perform certain actions is the basis for OAuth and protects your identity from being used by others.

In the social networking world, FriendFeed allows services to interface with the API using a username and key that is separate from the password (Oauth in a nutshell). Other sites that tell you to use a secondary password or a key are operating under the same premise. Twitter also supports OAuth, but has little documentation on using it.

While OpenID mainly controls your information for websites as a whole, OAuth is primarily used for API access delegation. With OAuth, you can share information between websites without handing out your username and password. Neither one can (or should) be used mutually exclusive from the other service. Not all sites support OAuth, but it’s a growing trend that is catching steam.

Interested in a more in-depth analysis of OAuth? Check it out on Hueniverse.