In defense of OAuth 1.0a

Yeah, I’m late to the party, sue me if you want Smile (I’m also late with my Indiana Jones stuff, I know). Anyway, I’ve just finished implementing OAuth on both a server and client, using .net for an additional challenge,

OAuth 1.0a is a decent protocol. One of the things it gets right is also the one biggest problem: The weird parameter reordering to create the HMAC-SHA1 signature. From what I’ve read, this was because the PHP installation on a certain webhost didn’t give access to the raw QueryString, hence this mechanism was created.

It’s the single biggest issue, but it also shows how the web works: There is a huge web hoster that has a limitation. The purist in me wants to say “Screw that Host” but at the end, you want adoption, and that means catering to the lowest common denominator. On the other hand, the OAuth guys kept HMAC-SHA1 as a security mechanism.

If you get this part right, OAuth 1.0a is a simple and elegant protocol. Really, it’s awesome. It has one downside that is a problem on mobile apps: It expects you to hit a service through HTTP and wants a callback URL. Some Services (e.g., Twitter some time ago) allowed you to hit their OAuth endpoint and get a numeric code that you could use to verify the request (which is neat for desktop apps), but it’s not really standardized.

The other problem: Access Tokens in OAuth 1.0a aren’t meant to expire, and you can’t really use it from JavaScript. If you want JS, the best solution is to hit your own backend which makes the OAuth request. And expect Access Tokens to expire.

OAuth 2 was supposed to fix this, but oh boy, this protocol is such a heap of garbage I don’t even know where to start. Luckily, one of the guys working on the Spec wrote it better than I could do.

If you are working on a Service Provider – either on the Internet or an Intranet – take the time to read up on OAuth and don’t make the mistake to discount OAuth 1.0a as “old stuff” and 2.0 as the new hotness. OAuth 2.0 offers some improvements for mobile phones, but it makes all security optional and has so many implementation details and additional complexities, implementing it may be a pain (also, some services are still on old versions of it).

Seriously take a look at OAuth 1.0a. If you’re on .net, look at DotNetOpenAuth which does a good job implementing it for servers and clients alike. There is not much documentation, but download the source and look at both the samples and the source. Also, use Fiddler to troubleshoot. The beauty of HTTP is that we can troubleshoot stuff super easily.

There are still a lot of headaches around testing, but if you find yourself in a situation where you need to solve the NTLM double hop problem or other similar situations where you have clients you can’t trust, OAuth 1.0a is a good protocol to look into.

RFC 5849 standardizes it (the RFC says OAuth 1.0, but it’s 1.0a).