In which I write a bit about my work at Twitter.

OAuth—the authorization standard that sits between applications and the Twitter API—has been in use across the web for around four years now, and has become quite successful. It’s been the exclusive means of accessing Twitter data since August of last year.

At its core, the OAuth mechanism is great. It allows users to embrace third party applications, safe from sharing their password with a third party; safe from that password being stored by a third party, or anywhere, where it could be exploited; and safer in that these applications have limited scopes to operate on their accounts. Finally, there’s a simple, central way to revoke a application in isolation, without the disruption to all a user’s apps when changing a password.

Where Twitter’s OAuth implementation has been weaker, though, is in clearly communicating these capabilities to users. The hop from application to service provider and back is simple—even in native environments, thanks to protocol handlers in every major OS. The concept of only providing your username and password to the service that’s issued it is logical, too. But Twitter’s interface needed to do better to inform users of what an application is capable of, and make it clearer what they’re allowing access to, which applications can post on their behalf, and certainly not leave people confused as to what ‘read and update’ might mean in context. We want users to try using more applications with confidence.

So today we pushed out a big improvement in how users authorize apps.

Third party applications themselves are now better illustrated. Logos, developer names, URLs, and descriptions are presented to coherently bridge applications and Twitter itself, and make it clearer that it’s a third party being authorized.

Gone is the generic ‘read and update’ terminology that abstracted the real implications of Twitter’s two scopes. Instead we’ve broken out the major capabilities an application has, in language consistent with the features of Twitter. What’s more, we reassure users of what an application cannot do. If your app only reads Tweets, it’s really clear that clicking ‘Authorize’ won’t put the user at risk of any unpleasant surprises.

Also, the new pages use a generous dose of CSS3 media queries to scale down text if you auth in a narrower window, and redraws the entire same mark-up for tidy display on smartphones. We want to make OAuth on mobile really, really good. (Plus, I’ve been having too much fun doing simple things with media queries lately.)

We hope that the new copy gives users greater confidence in applications, and encourages application developers to consider carefully the access scope they need. To aid that, we have some more goodies. Firstly, any application with a read scope can still integrate users posting to Twitter (and following users) by integrating Web Intents (simple web interfaces for the main Twitter actions, which we launched a few weeks ago.) Secondly, we’ve fixed some long standing bugs in our OAuth back-end that means the scope of tokens can be reliably upgraded and downgraded: Developers can consider authorizing with read-only access initially, and have their user upgrade to read-write if they need it later.

With the new views released, we’ve got more work to do around the user experience. We’re going to do more research, and we’re going to follow up in the not-too-distant future with better documentation about implementing OAuth experiences, and later on we’ll write more about how approval rates vary depending on the scopes requested, to help developers design even more successful apps.

---

As an endnote, I came to Twitter six months ago on the back of writing about how OAuth user experiences could be improved with this sort of scope breakdown. Twitter reached similar conclusions in their own research, and since I joined it’s been a lot of fun to pick up this project, and work with a really, really good-looking group of people see it through to a real shipping improvement. If you too want to help make everything a little bit better, get in touch (and follow @jointheflock.)