Hacker Confronts the Coming Twitter OAuthcopalyse with SuperTweet

He builds a new tool to patch the broken one. At least that is what David Beckemeyer (Mr Blog) did when his tweeting garage door opener was threatened by the approaching OAuthpocalypse. This date with destiny for all Twitter programmers is the planned June 30th cutoff of basic authentication. At that point all Twitter apps must communicate with the API through OAuth authentication instead of the much less complicated user name/password form of HTTP authentication. There are many good reasons for this change, which have been repeated endlessly on the Twitter developer forum, but in practice it is a lot of added complexity, more complexity than David wanted to build into his little, simple garage door device.

David made this point on the Twitter Dev group, and the response from Twitter HQ was "Why not have the controller proxy through a full-featured webserver that can OAuth in to Twitter". So David did just that, but in the true tradition of hackers, he built a tool that everyone in his position could use, and so SuperTweet was born.

Here is how SuperTweet works. A Twitter API developer logs into the Twitter account that he wants to be able to access through his code. He then goes to SuperTweet.net, and creates a new account with a password for using the proxy service. SuperTweet uses OAuth to authenticate this user's Twitter account, and stores the user's authentication credentials. The deveoper can then call SuperTweet with a Twitter API request and his SuperTweet password. SuperTweet makes the authenticated call to the API, and returns the result. These API requests are registered against the developer's account, not SuperTweet. So Twitter has the control they need to prevent abuse, no Twitter passwords are exposed to the big, bad IP sniffers, and the developer is shielded from the entire OAuth exchange. Everyone is satisfied. If this sounds complicated, take a look at what it really takes to do OAuth.

David doesn't see this as an answer to all Twitter apps needing to do authentication. He says that "if they really need to do OAuth, they should build it into their code." SuperTweet is definitely not an answer for any app that needs to support multiple Twitter accounts, each of which must be authenticated separately. But if all they need is a "bridge" for simple apps that tweet to a single account, SuperTweet is an appropriate solution. At the very least it will buy API developers some time while they wait to see how Twitter handles millions of malformed OAuth requests a day.

Even with these limitations, scaling SuperTweet will be a challenge if it gains wide adoption. David's LinkedIn profile explains that he served at EarthLink Inc. 1995-2006 as Vice President Engineering and Chief Technology Officer. At EarthLink, David was responsible for building and scaling EarthLink's technology infrastructure and research and development efforts." So I think he knows a few things about scaling message queues.

The funny thing is that David's original garage door opener was just a fun project, while SuperTweet has the potential to be a real money making product down the road. Proxying Twitter API requests can serve many purposes, not just solving complexity. For example, a true Twitter app needs to cache API results in a database, which may be require more server power than every developer has. A proxy service with a back-end database would make a lot of sense, and sounds like a fundable start-up. At a minimum this makes a great form of resumeware for David's consulting work. He is offering to help companies make the transition to OAuth if the free SuperTweet service doesn't satisfy their needs.

Don't be surprised to see a form of the SuperTweet OAuth model built into the Twitter API eventually, since many developers have asked for some version of this simple approach for server-based apps that tweet to a single account. @ replies, RT retweets, and # tags were all adopted first as user conventions, and incorporated later as part of the official user experience. Now it is up to the developer ecosystem to lead the way as well.

Comments(7)

This a horrible idea. It defeats the purpose of OAuth, and stores user credentials on a 3rd party site for developers that are too lazy to implement a few lines of code and talk to Twitter via the proper means.

I am doing a hybrid solution. Using Net::Twitter, I set up oAuth and got it working - pretty much. But for status updates, Net::Twitter doesn't work on my server, due to the 12+ perl module dependencies. So then I found SuperTweet.net - AWESOME! Does just what I need, let's me post status updates. I can do all the other stuff in my native perl code. Love it love it love it! And I will be donating to the author.

It stores the user's OAuth credentials, so users have the same control and security benefits they would with any other OAuth site. More importantly, Supertweets is not meant to be used to access Twitter on behalf of another user. As the article says "SuperTweet is definitely not an answer for any app that needs to support multiple Twitter accounts, each of which must be authenticated separately." It is designed to solve the problem of a simple script that only manages a single account that is most likely owned by the author of the script. In that case a full OAuth implementation is a huge level of overkill.

This is exactly what I have been hoping for ever since I heard about the transition to OAuth. I develop a bot that has a plugin for twitter, just to post a status. The password for the bot is stored in a config file on the user's hard drive along with the bot, so there are no passwords exposed to me. I didn't apply for XAuth because my projects are all open source. I hope twitter has some compassion for open source software developers and makes this a standard.