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.
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
it.
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
page that used JavaScript to call the Twitter API and render
results.
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
api.twitter.com. 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
Hammer-Lahav, who is the editor of OAuth 1.0 and also an
editor of OAuth
2.0, 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
become.
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.
Related: