Twitter kills the password anti-pattern, but at what cost?

Assertion and delegation of identity can now be easy or safe. But we need both.

Last week Twitter ended basic name/password authentication to its API.
This was announced well in advance. Still, like many
procrastinators, I found myself scrambling to learn what is now the
only available way to authenticate to the Twitter API: OAuth.

Some people can visualize how these kinds of protocols work by reading
specs and flow diagrams, but I’m not one of them. For me it doesn’t
really sink in until I create a working implementation. So I embraced
the opportunity to solidify what had been just a theoretical
understanding of the OAuth protocol.

I’ve also long embraced the principle that motivates OAuth. You should
never have to give your name/password credentials to a third-party
application or service so that it can impersonate you. This so-called
password anti-pattern is profoundly wrong. When legitimate
applications and services ask for permission to impersonate us, we
learn that it’s OK to do things that way. It isn’t. Malicious actors
can and do exploit our willingness to give up our credentials.

How can I authorize a third party to access my data on a service like
Twitter, and use its capabilities on my behalf, without giving it my
credentials? OAuth is a clever solution to this hard problem. A third
party that would otherwise need my credentials to do something can
interrupt the transaction, send me to Twitter where I authorize it to
act on my behalf, save a token that represents that authorization, and
then resume the transaction.

In my case, though, that’s a solution to a problem that I didn’t have.
OAuth is a three-party protocol. It typically involves a user, an
application or service that the user authenticates to directly, and a
third-party application or service to which the user delegates agency.
The elmcity/Twitter scenario, though, is really just a two-party game. As I discussed
in “The
power of informal contracts
,” the elmcity service uses Twitter as
a channel for authenticated messages sent from event curators to the service.

Here’s how it works. If you’re the curator of an elmcity hub, you can
associate your hub with a Twitter account. The elmcity service, which
exists in Twitterspace as @elmcity_azure, will follow your Twitter
account. That enables you to send direct messages to @elmcity_azure.
The service reads and reacts to messages sent through this trusted

In this scenario there is no third party. As far as Twitter and the
curators are concerned, the elmcity service is just another Twitter
user. Of course it isn’t a human sitting in front of a browser, but
rather a service running in the cloud. So it has to use the Twitter
API to follow curators, and to read the direct messages they send to

When I had the idea to do this, the implementation came quickly and
easily. Why? Because the activation threshold was low. Until recently,
it was dead simple to access the Twitter API, using HTTP basic
authentication, in order to try out interesting ideas. Earlier this year, for
example, I wondered what it would be like to visualize the names of your Twitter lists as a tag cloud. I sketched a
solution using a simple web
that used JavaScript to call the Twitter API and render

The page asked for your Twitter name and password, but I explained
that things weren’t as they might have seemed:

The first time through, you’ll be prompted to authenticate to This looks like the password anti-pattern, but really
isn’t. You’re authenticating yourself to the Twitter API in the same
way that you normally do to the Twitter website.

When you try that page now, the Twitter API responds:

{”errors”:[{”code”:53,”message”:”Basic authentication is not supported” }] }

Are there JavaScript libraries that would enable me to recreate this
app using OAuth? Yes. Will I bother to acquire, evaluate, learn, configure, and
use them? No way, life’s too short. And anyway there’s no great loss here, it
was just a sketch of an idea.

What is lost, though, is the possibility to sketch a lot of other
ideas. The unexpected way in which the elmcity service uses Twitter
is, I argue, an interesting and useful model. Having concocted it, I
went to a fair bit of trouble last week to move it from basic
authentication to OAuth. In a companion article at
O’Reilly Answers I share what I learned about libraries, tools, and
techniques that can help developers work with OAuth. It’s a
complicated dance of cryptography, redirection, and callbacks. So
complicated, in fact, that if I’d had my idea today instead of six months ago I probably
wouldn’t have bothered to jump through all the hoops.

According to Eran
, who is the editor of OAuth 1.0 and also an
editor of OAuth
, the 2.0 protocol will make it possible again to sketch ideas
using simple tools:

OAuth 2.0 provides a cryptography-free option for authentication which
is based on existing cookie authentication architecture. Instead of
sending signed requests using HMAC and token secrets, the token itself
is used as a secret sent over HTTPS. This allows making API calls
using cURL and other simple scripting tools without having to
canonicalize the request and sign it.

Good! But OAuth 1.0 is only now gathering momentum. OAuth 2.0, which
isn’t backward-compatible, will require its own long runway. I’m glad
to see Twitter driving a stake into the heart of the password
anti-pattern. But the Twitter ecosystem wouldn’t exist if it hadn’t
been possible to sketch ideas, and to explore the unanticipated uses
that can emerge from the soup of active ingredients that the web has

We must not teach people to give up their credentials and expose
themselves to attack. We must, however, teach them to savor that soup
of ingredients, to expect novel concoctions to arise from it, and
where possible to create their own. These innovations require us to
assert and delegate our identities. Today that can be easy or it can
be safe. Until it can be both easy and safe, we’ll be forced to make
painful trade-offs.


tags: , ,
  • What you are looking for is called Two Legged OAuth. You’re authorizing between the client app and the server, the user itself is not so important.

    Now with twitter, you can’t do things to the site, without doing them as a user. So you’ve got three legged oauth, you just need to know that you’re controlling both the client and the user, so it’s pretty easy.

    • The two-legged variant doesn’t get much play, and I hadn’t known about it, thanks for pointing that out! As you note, though, this ends up being a three-legged scenario in which I control two of the parties. It’s doable, and I am doing it, but easy it was not :-)

  • Though OAuth 1.0 is complex compared to basic auth, it reflects the requirements of a more complex world. These days developers need to understand delegation, assertion, tokens, etc in order to play in the ecosystem.

    That being said there is perhaps a lack of good tools for getting started with OAuth 1.0. The best I’ve seen so far is Google’s OAuth Playground, which walks you through each step of the process and shows all the messages being passed back and forth.

    As a maintainer of an OAuth library (Perl) the most common question I get is ‘my signature failed and I don’t know why’. So perhaps the crypto element is bulk of the higher activation threshold. Another roadblock is that various service providers add custom OAuth extensions that are not supported in all the libraries, and this lag causes yet more developer pain. Hopefully OAuth 2.0 addresses these issues, and helps converge the service providers’ extensions into a more complete core spec.

  • I am not very technical but was always a bit suspicious of authorizing a third party to access my data on Twitter, and other sites for that matter, I am only now realizing that I was right :-)

    There must be so many non-techies out there though just accepting everything as it pops up on their screen. This is very worrying.

  • Eric Falconer

    Arstechnica has a great write-up on a far more troubling issue with Twitter’s OAuth implementation.

    The issue is that twitter forces desktop applications to include their secret key, which is a huge no no – a problem that facebook / google have solutions for (outlined briefly in the article).

    It is fairly trivial for someone to extract this secret key with some debugging tools (several people have already demonstrated finding and extracting the official twitter key) and once a key is found to be compromised, twitter has said they will block access to that application.

    So someone downloads your app, extracts the key, posts it to a blog, and suddenly your app is blocked from the API. In the case of an iPhone app this could potentially kill it since it would take a long time to get a new version re-certified that has a new key, and many people will have simply moved on.

  • Zoo Jing

    OK this makes a lot of sense dude.

  • cori

    Not having an app in the twitter coral reef I don’t have much of a stake in this matter yet, but I do have some ideas kicking around that I’m interested in sketching out.

    So I’m curious; is the effort required to build up to a working knowledge of the OAuth framework in any given space or language transferable? I mean now that you’ve done it for elmcity, does that bring the OAuth Dance complexity back down to the level where sketching ideas become feasible again – just a one-time learning curve?

  • bob

    At the cost of free MINUS the exact cost of your identity being stolen.

  • Some of my wordpress-blogs, i wondered why i should update the twitter authentication. Some wordpress-twitter-plugins are not available since changing to oAuth. For non-techies it isn’t possible to understand what to do.

  • Jeff S.

    This concept of not divulging information to third parties directly – it’s something I first thought about, around 8 or 10 years ago.

    I wasn’t thinking about it in terms of user login, but a different form of user authentication – online commerce transactions. It always bugs me having to give out credit card info to make purchases online. One ‘solution’ to that problem is using something like Paypal – the problem is, paypal is yet another third-party being added to the transaction/trust chain, which I find undesirable – I’d rather being dealing just with the merchant and Visa/Mastercard/Amex/Discover (whichever network my card is part of); also, not every site supports paypal; thirdly, I don’t like the thought of paypal being a monopoly on such a service online, with no one being able to compete with them, but for such a scheme to work, it’s not desireable to have 1/2 dozen different systems which vendors have to support.

    Anyhow, point is, it occured to me in the early 2000’s that a *better* system for online payment would have users being temporarily sent from a merchant’s online store over to the Visa/Mastercard website, where the user would authenticate, review the proposed transaction (e.g. make sure the dollar amounts the vendor submitted to the CC company matched what they agreed to purchase), then authorized (or decline) that one transaction, then the CC company site would redirect users back to the merchant (and as part of that redirection, would include a one-time-use transaction token which that merchant would use when submitting a request for payment from the CC company.

    Initially teaching people to use such a system securely would be a bit of a burden, but the security of never giving *re-usable* credit card account information to online merchants seems like it would be very desirable, no?

    • @Jeff S. I love the concept of one-time credit card numbers, it’s been tried here and there, I always hoped it would catch on, but so far not. One problem was that it was web-only, and really needed to also work at the bricks-and-mortar point of sale. As smartphones proliferate that may finally become possible.

  • I joined eBay right after we had our own version of this type of migration. In 2004.

    One of the lessons we learned is you need to have a very simple web tool that allows a developer to have the site generate authentication tokens for themselves. Because there are a lot of people who write application for just one single customer, who is almost always them, or a member of their company. So, why bother making them implement the general sign up flow for the specific use case?

    Of course, with OAuth, you still need to wrangle with the signature base string (which eBay avoided by using SSL for all communications). Which causes even more trouble than the rest combined, unfortunately.

    • @Adam “Of course, with OAuth, you still need to wrangle with the signature base string (which eBay avoided by using SSL for all communications). Which causes even more trouble than the rest combined, unfortunately.”

      It sure does. One thing that helps is for the service to report the signature base string when an attempt fails. But requiring one at all is a huge obstacle.

  • I was just as frustrated by Twitter’s OAuth as you were. It really makes no sense for those that use Twitter in a private network for private purposes. But so be it. After lots of wrestling, it turns out it’s not as clever as they thought. Think of it this way. In lieu of divulging your Twitter username and password, you now provide username2, password2, username3, and password3. And these four entities can be different for each application you wish to activate. Problem was that Twitter has made it next to impossible to get all 4 of these credentials, and they sure as hell haven’t documented it well.

    In the end, we wrote a simple web page on the Internet that will let anyone decipher the 4 magic codes. You’ll just have to trust us not to steal your codes which long-time readers of Nerd Vittles never had a problem with. For details, visit this article: Then read the section on TweedleD Setup. You can use it for any Twitter application, not just ours. Good luck!

  • jrep

    The biggest danger with OAuth is that it sends developers down these rabbit holes of implementation details, alternative patterns, and standards progressions, entirely missing the more fundamental problem that the end user is still giving away incredibly valuable information, very nearly as dangerous as the credentials themselves.

    To the end user, all OAuth dialogs look the same. While OAuth provides means for the authorizing app to restrict the rights granted to the client app, there’s still no adequate way to enable end users to judge the effects of their decisions. All too compellingly, they consider “do I want this one thing I’m trying to do right now” (a question whose answer is always “yes”), and neglect, or are denied, any consideration of “do I want all the other things this client app might do with this permission?” The core problem is granting no more rights than the end user intends, and given the complexities of the possibilities on the one hand, and the near guarantee that the user has something other than “rights management” on their mind at the crucial click, this is a problem that OAuth does little to solve.