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.
I haven’t used xAuthTwitterEngine in Chirpie, however my implementation was exactly the same, a re use of Ben’s OAuth code, removing the web authentication interface and replacing with a user:pass API call. I just wasn’t brave enough to release it to the world as I’m still learning! Anyway, have fun!
Similar Articles:
Chirpie for iPhone Released to the App Store
Chirpie 1.1 Available in the App Store
Learnings from my iPhone App Submission Process
Chirpie 1.2 Available in the App Store
Introducing Chirpie for iPhone
Tags: Basic Authentication, Chirpie, OAuth, Twitter, xAuth
Hi Steve,
Why did Twitter not use Digest Auth? It seems to be made purposefully as an imprvement to Basic Auth to avoid passwords going over the wire in the clear.
http://en.wikipedia.org/wiki/Http_digest_authentication
Thats really nice. I suppose that would be compared to the permanent sessions in the Facebook platform.
Applications using Basic Auth show up as being “from API” not “from web”.
Why do you feel the standard OAuth flow with a custom callback to you application does not work for iPhone applications?
It’s not that they do not work, the user experience is pretty rubbish, flicking from native application, into a web interface, then switching back. It’s just clunky and inappropriate for non-web applications.
And sorry, using basic auth shows up as coming “from web”. I should know, I’ve been seeing it from @ChirpieApp for the past week pre implementing xAuth. The screenshot above is a real screenshot of a tweet from Chirpie ala “from web”
Im sorry for noob question (i’m super new to OAuth [though not the Twitter API]), but how exactly is the access_token script on twitter’s server supposed to know what your client you are from if you pass only the x_auth_XXX parameters, and don’t pass the other standard OAuth params like oauth_signature or oauth_consumer_key?
Thanks, Zapp Jackson.
Great post, exactly what I needed. Thanks!
I believe that xAuth is specifically rolled out for developers to exchange all of the username/password combinations they have stored for OAuth access tickets. This is a migration mechanism only (that’s why it’s on a per-application basis). As far as I know, it is only going to be available for a limited time (probably until shortly after basic is dropped in June).
@Ricky – No it’s not I’m afraid – how would an app support future users if this service will only be temporary. Kind of defeats the idea completely.
xAuth is a replacement for basic auth if you don’t want to use oAuth. It’s not going away.
Hi Steve,
If I understand correctly, setting up your application on twitter is not enough is this correct? I.e. By default they set it up for oauth, but not xAuth; You need to mail them? I ask because I’m still awaiting a response from Twitter, but when I tried it I keep getting “Failed to validate oauth signature and token”.
I’ve tried both https://api.twitter.com/oauth/access_token and https://twitter.com/oauth/access_token
as the end point.
Thanks.
Dermot.
Nice write-up on OAuth. I see xAuth as an appropriate extension to OAuth for mobile applications that operate on the behalf of a single client. I too managed to get OAuth implemented in TvvitterBug pretty quickly from scratch, thanks to the help I received from our friends at Twitter. I think they do a great job supporting their developers.
Twitter is really a good way in keeping yourself updated with the day to day activities of your friends and families members. I update my Twitter and personal blog daily.
Where do you store the xAuth token?
Wherever you want – usually a database, call it when the user needs it.
Nice write up… I got exactly which i want… Thanks Steve.
If you are going to the trouble of adapting your app to use xAuth, why not go the extra step for your users and use OAuth?
This boils down to developer laziness IMO, and laziness is not a tradeoff for security, I don’t want anything touching my username/password except the absolute essentials, your app might be storing them for some purpose, how do I know?
In addition, I echo Zapps comments, how it Twitter going to know what application the access tokens are coming from? Unless they are tied in to the tokens you receive back somehow? Thats what the request token is for in the OAuth impl.
OAuth on mobile such as iPhone just plain sucks, that is the point of XAuth, to make OAuth on mobile a better experience.
Show me a good OAuth implementation on mobile and I’ll move to OAuth in an instant.
they are just making things complicated. I mean, even if they implement oAuth/xAuth, if the developer really meant to get access to any user’s twitter account, it can do so because the users will never know.
If you’re able to write down a so clear and simple explaination of OAuth and XAuth, you should have no fear to release your code to the world
Im a starter iphone developer and this post has been extremely useful!
great post, great app!
Giuliano
This article is ace! I need to access my own twitter account from an app I’m doing to get some content stored there!
I can’t wait to get some time to try it out!!
Thaaaaanks!!
I’m sorry @steve, this is not developer laziness, and there are some gaping holes in your arguments:
1. If I want to grab the users key-presses from the displayed oAuth authorisation page, a developer could do that. This is no more secure if you believe the developer is not trust worthy.
2. One might say that developers not being determined to get a better solution than “display a random web-site UI look and feel in the middle of my app that might change at any point” would be developer laziness. You are prioritising perceived security over usability. An application and its functionality should be consistent with its environment.
The decision is very simple. If you believe that using xAuth is lazy and the work of a bad developer, vote with your wallet/time and go use another App that uses the full oAuth methodology. The point is there are plenty out there and it’s your choice.