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

 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 channel.

more @ http://radar.oreilly.com/2010/09/twitterss-oauth-mandate-kills.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+oreilly%2Fradar%2Fatom+%28O%27Reilly+Radar%29