OAuth, Auth, wherefore art thou Auth?

on November 23, 2010

Being at the airport with some time to kill, I figured I’d try to get through some blog post topics that I’ve had queued up for a while. More accurately, I might call it a stack, because I’m going to start with the most recent topic first, which was a fun little detour I took this weekend trying to integrate Twitter with MonogramX.

For background, the Twitter integration feature was something I had said I would do for a long time, and by the time this weekend rolled around, I was positively ready to just lay the smackdown on it and get it out the door. So I pumped myself up, and took off on the interwebs to read up on how to do it.

Somewhere along the way, however, I forgot to think critically, and so when I came across blog posts talking about OAuth, I naturally assumed this was something that I needed. I had heard it in passing before, and it had a cool name. That totally means that I needed it, right?

So what is OAuth? Since I don’t have the internet right now, I can’t look it up and turn around and tell you as if I knew it all along. Instead, I actually have to try to explain it in my own words. Based on what I’ve tried with it (and I’m assuming I’ve only tried a subset of its features), it’s a way to authenticate a user with a third party, with whom that user already has authentication credentials. I almost see it as a kind of three-way handshake (although I am not sure if that’s technically accurate, but it certainly has that feel to it). In any case, the real-world application I was going for here was to let a user authenticate with their Twitter account so that MonogramX could read their feed. (Astute readers will notice that something is not quite right with this last sentence—isn’t this story suspenseful?)

After a few frenzied hours of hacking, I had gotten OAuth to work. For those already familiar with OAuth, you may remember a time when you initially had to learn it. I suppose in retrospect all of it makes a lot of sense, but to learn it on the fly can certainly be confusing. It also doesn’t help that everyone calls the main concepts different things. As a public service, I’ll try to distill some of the vocabulary, in case someone on Google comes across this and finds it helpful.

So the first thing you need with OAuth is a provider and a consumer. The provider is usually the place where the user has an account (in this case, Twitter). As a developer, you are the OAuth consumer. But to be an OAuth consumer, you are actually going to be a few different things over your lifetime.

First, you will identify yourself to the OAuth provider as the signing consumer. This usually involves registering with the OAuth provider ahead of time (say, through their web UI). Through this process, you acquire a consumer key and a consumer secret. I’ve also seen these be referred to collectively as “the consumer token”; yet I’ve also seen “consumer token” to just mean “consumer key.” Regardless of the verbiage, being the signing consumer is probably the easiest part of being an OAuth consumer, since it’s pretty straightforward.

Once you have the consumer key and secret, you will send these to the provider, who will respond with a one-time request key and request secret (again, I’ve seen these be referred to collectively as the “request token”). The request token is essentially a way for the OAuth consumer to convince the OAuth provider that the OAuth consumer really is the same OAuth consumer that will be around later on. This is because as soon as you (as the OAuth consumer) receive the request key and secret, you have to send the user off to the OAuth provider’s website to authenticate themselves as they normally would with that provider. You also provide a callback url that the OAuth provider will redirect the user to upon successful authentication.

The callback redirect is basically why the request token and secret matter, since at that point the OAuth provider isn’t really sure that you are the same entity that originally asked for the request token. By showing that you still know the request key and secret, you are effectively confirming your identity.

As the OAuth consumer, when you receive the callback, the OAuth provider will give you a verifier secret to let you know that the user successfully authenticated. Now that you can (a) show that you are you and (b) show that the user logged in, you can combine it all together to get the access key and access secret. Once you have this access key/secret pair, you have the (near) equivalent of the user’s username and password. The reason having the access token isn’t exactly the same as having the user’s true credentials is because the user could always login to her account separately and revoke your application’s access afterwards. That would effectively render the access token that you (as the OAuth consumer) have invalid.

So there you go—that’s the idea behind OAuth; in summary, it’s a pretty clever way to proxy the user’s credentials through a process that has the properties that (a) the OAuth consumer is the OAuth consumer; (b) the user is the user; and (c) the OAuth provider can revoke access from any OAuth consumer.

In my case, I wanted to integrate MonogramX with Twitter for the purposes of displaying the n most recent tweets from that user. And remember what I said about thinking critically at the beginning of the post? Well, if I had done that, then maybe I would have realized that tweets are public. You know, like the kind where you can just open up a browser anywhere and see. Where in any of this did I have to authenticate again? Yup, five hours down the drain. To summarize, that’s:

git branch -d feature/twitter_feed

Although I suppose the hours I spent trying to figure this out weren’t a complete waste. After all, OAuth is pretty up-and-coming these days, so having learned the basics can only help in the future. If I had to identify the moral of the story, I would have to say that it’s the clichéd adage “think twice, code once.” Somehow, I seem to forget this nugget of wisdom every once in a while… It’s nice to get reminders.