OAuth 2.0

Posted on May 20, 2010

I’ve been updating my OAuth library to support OAuth 2.0 mostly so I can add Facebook to Announce.ly and Sproozi, but more on that later. OAuth 2.0 is similar to 1.0 but changes a few key things fundamentally and isn’t backwards compatible.

What’s wrong with 1.0, doesn’t it work?

It does, but probably the biggest issue is the fact that you have to sign the message knowing all it’s content beforehand. This works well if the data is on the querystring in a GET request or for simple operations but isn’t optimal if your data is part of the POST body. It also means you have to construct your requests in a certain way, which is a bad thing.

Take photo, audio or video data – to post that you’ll need to sign the whole request and it’s not clear how it should work with multipart data. There are several extensions to the spec that deal with some of these issues, but the fact that there are non standard extensions to do something pretty standard kinda says it all.

Even if you’re not dealing with these issues you still have to work with your requests as units where you know the whole content beforehand.

What’s new in OAuth 2?

OAuth 2.0 in it’s simplest form works over HTTPS connections and simply asks for a token – the security and trust are built in to the protocol. It’s that easy.

OAuth 2.0 sill lets users sign messages to transmit them over insecure channels, plain HTTP, but the signing methods are much easier to implement. Gone is the complicated parameter normalisation algorithm and in it’s place is a much simpler version that doesn’t require POST data in the signature. So even with multipart submissions it should just work.

At the moment I’m cleaning things up and preparing the oauth library to work with oauth 2.0 and changing the way it works to reflect the simpler way oauth 2.0 does. You can check it out on GitHub [http://github.com/andrewmccall/oauth]

Another Open Source Library.

Posted on April 6, 2010

I’m having a bit of a clear out, taking a look at some of the code I’ve written and I’ve been pushing some of the stuff I’m currently using up to GitHub under and Apache 2 licence. I’ve used things in Announce.ly, Sproozi and some other small projects and figure they may be useful to someone else. My only criteria has been to ask If I’m using it now in a project, if so I’m actively supporting it and I’ve started pushing that stuff to GitHub, everything else is dormant and I don’t want to release something I’m not actively supporting- it also occurs to me that if even I’m not using it, it can’t be all that worthwhile.

I’ve just pushed some code I’ve been testing for a few months in a couple of projects to GitHub. It’s an accounts package written for Spring, that ties my oAuth library and Twitter together with either Hibernate or Hbase as backend storage. In it’s simplest form when you login with twitter it creates you a new user and persists it and the oAuth access tokens you need to act on behalf of that user.

I’ll write some more about it, better documentation and probably throw a little more code up on GitHub over the course of the next couple of weeks as and when I get a chance.

My new open source Java OAuth library

Posted on March 19, 2010

I’ve just pushed out a new open source java OAuth library because I couldn’t find one that did what I needed. My key requirement was simplicity. I didn’t like the idea of using the library for HTTP stuff and there is no reason I should. Once I’ve obtained the Access Token all I’m doing with oAuth is signing my requests.

I want to use HttpClient directly and only use the oAuth library to sign the message for various reasons not the least of which being that I already have a HttpClient object setup in my IoC container.

The closest I found was signpost but it wasn’t very IoC friendly or thread-safe which meant every time I wanted to make a call I’d have to create new objects, or at the very least call a bunch of methods to set them up which highlights the third problem, there were no clear objects that I could store for later.

The library I’ve just release is a fork of the signpost code, that’s now thread-safe and should be more IoC friendly. You create your method calls as you would normally, and just before you call HttpClient.execute(HttpMethod) simply call OAuthConsumer.sign(HttpMethod, AccessToken);.

I’ve added a few new objects that handle most of the work. Service, RequestToken and AccessToken are all beans that you pass to a consumer depending on what you want to do. Starting with a Service you call

Service service = new Service();
service.setRequestTokenUrl("http://twitter.com/oauth/request_token");
service.setAccessTokenUrl("http://twitter.com/oauth/access_token");

service.setConsumerKey("b8sA385mBBNqOTD6Omlsw");
service.setSharedSecret("MD4Sve6AdaDasjdvOAsbpAJsA87S8s64e5rE4");

service.setMessageSigner(new PlainTextMessageSigner());
service.setSigningStrategy(new AuthorizationHeaderSigningStrategy());

RequestToken requestToken = oAuthConsumer.getRequestToken(twitter);

You’ll have to send the user off to twitter to check their credentials. When they come back
they’ll be given a verifier set it and trade the request token for an access token

requestToken.setVerifier(verifier):
AccessToken accessToken = oAuthConsumer.getAccessToken(requestToken);

Now you can store the accessToken to use later, when you want to simply setup your http method as you would normally.

HttpUriRequest request...
// do your HttpClient stuff here

oAuthConsumer.sign(request, accessToken);
HttpResponse response = httpClient.execute(request);

There is also code in there for the Jetty HttpClient, but it’s a bit rough and I haven’t used it. Have play with it and let me know what you think.

UPDATE: Forgot to link to it… Dumb. It’s on GitHub here.