Those of you following my tweets may have seen that I was rather frustrated this week at Twitter's oAuth policy with regard to desktop and mobile applications.

In a nutshell, Twitter requires any new applications that use the Twitter API to use oAuth for authorization if they want to display the source parameter in tweets. The source parameter is the little bit of text and the link to your app that appears at the bottom of tweets (e.g., via Tweetie). It constitutes a very important bit of organic marketing for Twitter apps.

My gripe – as a developer creating a new mobile Twitter app for the iPhone – was that this rule only applies to new applications. Existing application can continue to use basic authentication and display the source parameter. This currently creates an uneven playing field where new desktop and mobile applications cannot compete with existing applications on UX due the following deficiencies with oAuth and/or Twitter's implementation of oAuth:

1. Twitter's lack of a mobile-optimized oAuth screens
2. The trip to the browser is a major context change for the user for desktop and mobile apps. It is not the same as opening a new site within the context of the browser experience.
3. Cumbersome and convoluted UX for setting up multiple accounts in Twitter. Setting up N number of accounts means N number of round trips from the browser, each requiring the user to sign out, then sign in again before approving the new account.
4. The Consumer Secret is stored in a desktop/mobile client and thus is open to reverse engineering and spoofing. This nullifies the argument that oAuth is better for identifying clients when it comes to desktop/mobile apps.
5. oAuth recursive delegation is not a solved problem. How does a mobile Twitter client, for example, sub-delegate the authority it got from the user (in a revokable manner) to a service like TwitPic?

Alongside actively discouraging developers from creating new desktop and mobile apps, this policy also leads to user experience travesties like Echofon asking the user for their credentials before sending them to the browser where they have to sign in again. (All this just so that it can meet the requirement of "using oAuth" and display the source parameter while remaining competitive with existing apps that offer seamless integration with third-party Twitter services.)

As of yesterday, however, a couple of very exciting things have either been implemented or come to light that have almost entirely addressed my concerns with Twitter's oAuth policy (and which give me new hope for the evolution of oAuth on desktop and mobile).

Twitter launches mobile-optimized oAuth screens

A major UX flaw with Twitter's implementation of oAuth was the lack of mobile-optimized oAuth screens. This is how I described the existing user flow in my email to the Twitter Development Talk list recently:

Sending a user to Twitter's oAuth page after having slaved over every pixel in your iPhone app is like giving someone a ride in a Ferrari and then throwing them in a mud puddle before pulling them back in for the remainder of their ride.

I'm happy to report that Twitter addressed this yesterday and has launched mobile-optimized Twitter oAuth screens. This is great news! This new feature means that mobile Twitter clients that currently implement oAuth will get an immediate user experience improvement.

This does not change the fact, however, that the traditional oAuth flow – which requires a major context change on desktop and mobile applications – presents the user with a less-than-stellar user experience.

Since the browser redirection is a UX nightmare for mobile and desktop apps, it has often been circumvented by loading the oAuth authorization screen in a web control. As the Exposure iPhone App example in the previous link shows, this nullifies the advantages of having a trusted third-party application present the page, along with its URL, to the user. This sort of circumvention happens when the UX and practical concerns of one context (desktop/mobile) is not met by a solution that was originally created for a different context (web). It also leaves the user as open to getting phished by a malicious app as a regular credentials request and undermines trust oAuth itself.

I'm happy to report, however, that Twitter has gone several steps further to implement a pragmatic extension to oAuth that radically improves the user experience for desktop and mobile apps.

Twitter fixes oAuth for desktop and mobile with browserless xAuth extension

Twitter has implemented a new flavor of oAuth that I've started calling xAuth due to the x_auth headers that it uses. This is a radically different flow to the traditional oAuth experience that requires a round-trip to the browser.

The xAuth extension to oAuth allows clients to obtain a user's credentials and then exchange those for an oAuth token without a trip to the browser. It appears to be an implementation of the OAuth Access Tokens Using Credentials Internet Draft submitted to the IETF in March of last year.

Twitter's xAuth implementation is not open to the public yet but at least one app, Seesmic Look, is using it. Twitter has not given a timeline for when the feature will be available to other apps, stating that "it will be available publicly soon".

You can't imagine how happy I am to see Twitter implement this. It makes perfect sense for desktop and mobile applications which run in a trusted context (as opposed to web applications that do not).

Have no doubt about it, xAuth is a complete UX win for oAuth that makes it both usable and practical for desktop and mobile applications to implement and I look forward to seeing it become part of the standard.

oAuth Recursive Delegation

oAuth Recursive Delegation – where one client can sub-delegate the authorization it got from the user to another client – is not a solved problem at the problem. There is an Internet Draft on oAuth Recursive Delegation from September of last year but, from what I've been reading on both the oAuth and Twitter lists, no concrete implementation exists at the moment.

Currently, non-oAuth clients simply share the user's username and password with other services like TwitPic. This, of course, is a rather terrible practice but provides a seamless user experience.

Stop-gap solutions for oAuth, like sharing an application's Consumer Secret and Consumer Key, are not much better.

The way I see delegation working in oAuth is actually quite simple. Here's an example for a general-purpose mobile Twitter client (lets call it LoudBird) that uses xAuth:

1. LoudBird asks the user for her username and password
2. LoudBird authenticates the user with Twitter and gets an authorization token allowing it to Read, Write, and Delegate.
3. Since LoudBird uses TwitAwesomePhoto to upload photos, it asks Twitter for a sub-authorization token that delegates its Read and Write (but, in this case, not its Delegate) authorization to TwitAwesomePhoto
4. LoudBird provides this sub-authorization token to TwitAwesomePhoto when making requests and TwitAwesomePhoto uses it to update the user's account.

The advantages of this approach are several:

• The user can, at any time, revoke LoudBird's authorization (for example, because her laptop got stolen).
• The user can, at any time, revoke TwitAwesomePhoto's authorization (for example, if TwitAwesomePhoto is revealed to be a horrible spam machine from the depths of Atlantis).
• At no point does LoudBird share the user's credentials.
• At no point is the user's flow interrupted – the UX is seamless.

I'm going to go over the existing Internet Draft more carefully when I get a moment and – if it's necessary and won't be redundant – I'll flesh out the above flow in more detail.

Pragmatism and UX FTW

There is always a tradeoff between security and user experience. However, where security solutions ignore the practical requirements and needs of users and developers, they will either be ignored or, even worse, circumvented in the worst possible ways as demonstrated by the Exposure, Echofon, and TweetPhoto examples presented here.

Twitter's xAuth implementation is a timely and pragmatic solution that adapts oAuth to the needs of mobile and desktop applications. I applaud Twitter for taking the lead with this. I also encourage anyone with an interest in building good user experiences to do the same and I look forward to seeing xAuth become part of the oAuth standard.

I am giving a talk today at the Twitter Dev Nest in London on Twitterformats and I just got word that we have time for me to a second presentation on the latest oAuth developments at Twitter, including the hugely-exciting xAuth. Come down and say hello. The meeting kicks off at 6PM.

The Twitter fixes oAuth for desktop and mobile with xAuth article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.