Five things you didn’t know about xAuth.
xAuth is a new twist on the OAuth athentication system. It allows desktop applications to use the OAuth with and alternate workflow. The new flow is specifically designed for desktop and mobile and does not require that the applicaton open a web browser.
1. xAuth isn’t for everyone
xAuth was designed specifically to improve the user experience on desktop, mobile, and platforms where web browsers are not available. Web-apps should continue to use the original OAuth flow.
This difference in user experience is a recognition of the practical differences between web-apps and apps running on your own computer or phone. Most client applications on the desktop use the username/password pattern without any difficulty. xAuth lets us continue to use this pattern on the desktop where it’s working. Web-apps continue to use the standard OAuth flow, which prevents users from having to give their password away to an untrusted 3rd part.
2. Developers need to request permission.
Twitter rightly doesn’t want to let everyone use the xAuth workflow. They want to make sure that the folks that do use it have a real desktop or mobile app that needs it. Developers need to apply for it to be activated on your application, because it’s switch off by default.
To apply for xAuth, just send the API team an email. Make sure that you have a registered Twitter application already set up, then send an email with the app details to api@twitter.com. Make sure to explain your reasons for needing xAuth and provide them with as much real application information as you can.
3. One-time use exceptions for web-apps.
Despite what I just wrote, there is one way to get xAuth for web-apps. Twitter has stated that some web-apps will be given a one time use of xAuth to migrate all existing username/password users to OAuth. This is a great option for sites that have a large database of existing users that need to be moved before the Basic Auth cutoff coming in June. This allows web-apps to perform the move without requiring users to lift a finger.
4. xAuth doesn’t require Request Tokens
The normal workflow of OAuth starts by asking Twitter for a Request Token, then obtaining user authorization, then exchanging the Request Token for an Access Token. xAuth skips the first two steps entirely and jumps directly to the Access Token step. The normal token exchange is modified to provide the username and password instead of the normal request token.
5. Twitter didn’t invent xAuth
OAuth did come from development at Twitter with some of the early Twitter Developers a different group of folks proposed the xAuth modification. You can find the original draft proposal on the IETF website. Despite having x_auth in the authentication headers, I think the xAuth term was first coined by @raffi on the Twitter API team.
And there’s more
There are several other great sources of information on xAuth.
- Aral Balkan’s blog discusses the frustrations of OAuth for mobile and the lead-up to xAuth.
- Steve Reynolds blog has a great technical discussion on building xAuth in Cocoa.
- Abraham Williams’ blog has some techy details about how xAuth works in Seesmic Look.
- TweetDeck is using xAuth and blogged about the advantages.
- The Twitter xAuth documentation is always a good place to start.
Watch it go
If you want to get your feet wet and start developing right now, there are a couple great Obj-C demo projects that make it pretty easy:
- Aral Balkan’s xAuth Twitter Engine example is for iPhone. He also has a little write up about it over here.
- My xAuth Test App is very similar, but intended desktop.