Using xAuth, an alternate OAuth from Twitter

Steve Reynolds — Mon, 01 Mar 2010 13:00:22 +0000

In the last week Twitter did something interesting in order to quell the increasing noise from mobile and desktop app developers, that was – introducing xAuth to the wider web. Back in early February the Twitter API team announced the new xAuth authentication mechanism. Twitter hope it will fill the void of terrible user experiences mixed with web contexts into desktop and mobile apps experienced when using current authentication preference, OAuth.

Basic Authentication

Back when Twitter first launched it’s API they had what’s called Basic Authentication. A user of the API had to make all API calls directly with their username and password. iPhone apps such as Tweetie, Twitterrific and Birdfeed all use basic authentication. I myself used basic auth in Chirpie when I launched it 1 week ago.

From a dev perspective, basic auth is really simple – just make sure you store the username and password for an account, and re-use on every API call. However, Twitter deemed that from a security perspective, it wasn’t a great idea to be using the user’s credentials every single time they interacted with the API, they therefore decided to use OAuth. In addition, it’s required for any application that uses basic auth to store the username and password for re-use between sessions. Another no no apparently…

Twitter are now about to kill of basic authentication. Check out http://www.countdowntooauth.com/

Twitter Basic Auth Death Clock

OAuth

I won’t go into the deep details of OAuth, but the basic premise is this, an application gets a request token, and sends the user off to the source website (in this case Twitter) for a set of authorized tokens which it gives back to the application, and subsequently uses to exchange with the API instead of the user:pass :

OAuth Process

The problem with this is the “via web” part. For mobile and desktop apps, you have to leave the comfort of your application, and into a web interface in order to authorize the request. In addition to this, Twitter penalised anyone using basic authentication by stopping them from publishing their application name unless using OAuth (hence the developer outcry for some months). Example:

Twitter Basic Auth Vs OAuth/xAuth

It’s worth noting here, that in the old days basic auth apps could publish tweets using “via application name“, however early in 2009 Twitter stopped accepting registrations for basic auth applications, which is why some basic auth apps still come from their app name, like Tweetie, where more recent ones come from “web”.

On iPhone, leaving the comfort of a native app into a web interface (which was until recently not optimized for mobile) was a huge loss – therefore most iPhone devs from recent times opted for basic auth in order to keep a good user experience.

Enter xAuth

So xAuth is here to save the day… xAuth takes some fundamentals from OAuth in the sense that you still use your authorised tokens to interact with the API, however it’s the process of getting that set of authorised tokens that has changed. Basic auth developers can now exchange the username and password of their users for an authorised token set in one API call. No web interface required. Essentially:

xAuth Process

This stumps alot of people at first, there’s no process involved to get a request token, that’s all out of the door – it’s simply get the user’s credentials, make an API call, receive authorised tokens in return.

The downside of this is that the application is interacting directly with the username and password (in the same way basic auth did), so in essence is losing a large chunk of the security effect of OAuth (OAuth apps never see the username and password of the user directly, only the tokens).

There are alot of arguments around the web on the effectiveness of xAuth – to me it seems like its just basic authentication with a bit of extra security because each API call isn’t using the user:pass every time – in fact, to even associate it with OAuth for me is a little bit crazy.

That said, I am extremely happy. As a recent iPhone app developer, I was gutted to find that I could no longer register Chirpie as a basic auth app with Twitter, and subsequently couldn’t promote the use of it within Twitter unless I used OAuth.

Using xAuth

Using xAuth couldn’t be simpler actually. First off though, you need to send an email to api@twitter.com and ask them to register your OAuth application to use xAuth. Once approved (you’ll get an email at time of writing) you make a call to the API method “https://api.twitter.com/oauth/access_token” and simply send it 3 parameters:

x_auth_username - The username of the user.
x_auth_password – The password of the user
x_auth_mode – Set this value to “client_auth” (without the quotes).

This one method then returns you the authorised access tokens in the same way the same method does for OAuth. You should store the tokens as they do not expire, and reuse the tokens for any subsequent API calls. The password can effectively be forgotten after the authorised access tokens are received (unless you need them for third party sites such as TwitPic etc..).

It really is that simple, just one step. As long as you remember this key point (that it’s one API call, no request tokens needed etc), you will be setup really quickly. The Twitter documents aren’t so clear on this, and hopefully they will clarify a bit better shortly.

I managed to get xAuth implemented into Chirpie in about an hour, and submitted to the App Store. Such a small change, which I hope will make a huge difference to the effectiveness of Chirpie in Twitter.

Update – xAuthTwitterEngine

For those hoping to get xAuth working on an iPhone, Aral Balkan has just launched xAuthTwitterEngine, which is an update to the excellent MGTwitterEngine from Matt Gemmell, via an OAuth implementation of that by Ben Gottlieb.