As a personal project I’ve recently been looking into creating a small Twitter
client in Objective-C/Cocoa. This is largely because I quite like Objective-C
as a language and haven’t had the chance to write anything significant in it,
but also partly because
Twitter have made the news recently
with their API nuttiness and I wanted to play around with it.
So, I surfed over to the Twitter API docs to
take a look at how to implement the API. After reading and playing with the
API for a few days I’ve got some quite strong opinions on various parts of it
(few of them good), but far and away the defining characteristic of my
investigation of the API is OAuth.
OAuth Background
Of course, I’ve read stuff about OAuth before, so I knew before I got started
that it was highly controversial. As a result, my natural reflex was to avoid
OAuth if possible. A cursory reading of the API docs, however, shows that
Twitter pretty aggressively rate-limit calls to the API: 100 requests per hour
for non-authenticated users, 350 for authenticated ones. As a result, I was
definitely going to have to authenticate, and OAuth is their authentication of
choice.
This meant I’d have to use OAuth. Here, my problems began.
I Hate OAuth
Firstly, I had to familiarise myself with the OAuth authentication flow. It
turns out that this is nothing like as simple as I’d like it to be. To explain
why, I need to make sure you’re familiar with the niche OAuth is intended to
fill.
The purpose of OAuth is to be able to provide applications with access to your
account without giving them your password. This apparently simple notion ends
up being really quite complicated. In short, to achieve this, OAuth requires
that you perform the following steps.
- Register your application with your OAuth provider (in this case Twitter),
and obtain from them your Consumer Key and Consumer Secret. - When the customer starts up your application for the first time, send a
request to a URL provided by the OAuth provider with various OAuth headers
set in the HTTP, including your consumer key and secret. Some providers
(hello again Twitter!) also require you to set custom headers. This caused
me some unrelated difficulty.
This procedure should return an OAuth response that provides a ‘request
token’. - Send your user to a URL, along with the request token, to ask the user to
authenticate your application. For desktop applications, this involves some
bizarre out-of-band procedure involving PINs. At least Cocoa makes this
part easy. The user is required to log in. - This will either cause a callback to a different URL, or the user will
return to your application to input the PIN (or whatever out-of-band
weirdness your OAuth provider uses). - Now you need to make another web request (yes, really) to the OAuth
provider, this time to get an authorisation token. This token can be stored
away (e.g. in the OS X keychain), and has to be used to sign all subsequent
requests to the API.
Keeping track, that’s three web requests to obtain an authorisation token.
Additionally, for desktop apps, the user is required to context shift to a web
browser in order to authorise the application. This is a serious set of
disadvantages.
Here’s the thing: it’s really not worth it. Yes, we don’t have to put password
security in the hands of application developers, which is a huge advantage.
Yes, we don’t transfer the password information with each request, which is an
advantage.
Here’s the thing: it’s way too hard to get working. OAuth libraries are a pain
in the ass to write, and I don’t think I’ve encountered one yet that functions
perfectly. Additionally, the standard is a nightmare. The RFC for OAuth 1 is
35 pages long, and the lead author on
the OAuth 2 standard has actually withdrawn his name from the spec.
This complexity makes it almost impossible to guarantee how any single OAuth
implementation will behave, which makes very close reading of the relevant API
docs a must. Indeed, a subtle mis-reading of Twitter’s API documentation cost
me nearly a day of work single-stepping through code execution when the error
turned out to be in one of the HTTP headers instead.
It seems as though the complexity associated with OAuth must be unnecessary. I
am not a serious big-time web developer, and one of those people might be
better placed to judge the difficulty of the task, but I can’t help but feel
that there must be an easier way to achieve this. Certainly OAuth adds a
number of points of failure and a stunning quantity of boilerplate code.
It also discourages casual API exploration. When deciding whether or not I am
going to use an API for the first time, I usually fire up a Python shell,
import requests and start wandering through the API. OAuth adds some
significant hurdles to this process. I need to work out how to obtain my
authorised token with which I will sign my subsequent requests, and there are
some bugs present in the OAuth implementation in Requests that have not yet
been ironed out. (Shameless plug: do you know lots about OAuth? If so,
come help us out!)
All of this means that I am less inclined to use your API. I can’t be the only
person who thinks this when they encounter an OAuth-based API, and as a result
it is certainly possible that many developers who could have written killer
apps for a service have called it quits early. This is a terrible shame.
Fix It
So here is my plea: can someone please fix this? I don’t have the knowledge,
the skill, or the authority to attempt to replace or improve OAuth. I would
happily provide feedback on any implementation that seeks to replace it, but
I simply don’t have the prerequisites to develop it myself. That said, I
desperately want it. I want it to be fixed. So, for the sake of developers
everywhere, can someone step up to the plate?