Twitter OAuth in Beta - And what they SHOULD do.

2009 January 25
by Matt

Twitter have finally made a move against the issues with third party services using users primary account details for integration with peoples private feeds. Given the recent phishing attacks that plagued the twittersphere, people have realised the issues with trust over their private credentials, and the fear of extending a limited application with third party twitter-apps.

I say its not a moment too soon - this is something that twitter themselves should have implemented as soon as it became apparent that a lot of interest was being generated in services that interface with peoples private feeds. Whether this be a lifestreaming platform like friendfeed, or a simple desktop client like twhirl - any service that requires you to enter your username and password has complete access to your account, and can masquerade as yourselves, thereby opening up the issues to those who follow you.

Twitter have decided to tackle this by using OAuth, which in itself is probably the best way of implementing this level of security. Lets just hope they don’t make the mistake of not implementing an area in your control panel where you can revoke issued credentials - a key failure I’ve seen in a lot of half-arsed attempts at implementing the OAuth protocol (you read it here first ;)).

Twitter will need to revoke the current API’s authentication, otherwise some of the more “conservative” developers will keep using the old style authentication. People obviously don’t think twice when giving out their usernames and passwords, and that will continue. They need to implement blanket coverage, or the main issues with viral phishing have still not been addressed. In implementing this blanket change, all existing twitter apps will need to be redeveloped to account for the changes, implementing the somewhat more complex OAuth protocol in order to integrate with the twitter API.

Now, while i’m all for implementing OAuth for the primary method of integrating the twitter API, I would also look at providing a vastly simplified version, without the need for a lot of chatter between twitter and your client.

A simple way of doing this would be to have an area in your twitter account where you could generate subsidiary usernames and passwords for your account. For example, you could create the username “twirl@twitteruser” with its own unique password that you simply use inplace of your existing username and password when using the twitter API. You could assign permissions for that service, allowing it to perform only a certain subset of the full API. Best of all - it would be fully compatible with the existing API, allowing immediate rollout and implementation on all existing twitter services. Friendfeed offer a similar implementation they call “Remote Keys”

In all - I’m glad that twitter are making the change, and OAuth is certainly the best way for them to go. But why overcomplicate integration with the existing APIs. Keep the old one in place, remove the ability to use your master username/password and allow subsidiary credentials to be created on each account so we can simply replace our twitter details in the systems we already use. Oh - and how come its taken so long to do the obvious.

No comments yet

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS