An OAuth Provider for ABBI

My exercise for the past couple of days has been to build an OAuth provider for Java.  There are several reasons why I'm doing this.  The first is because when I started doing the security risk analysis, I realized that ABBI needs to be an OAuth provider, not a client.  My first implementation of Monday implemented the client.  Oh well, live and learn.

While there are plenty of OAuth Java frameworks for the client side, there were only a few for the provider side, and many of those required use of frameworks more complicated than I wanted to handle (e.g., Spring).  I suppose that someday I'll have to learn how to use these frameworks, but not right now.  I had already been using Scribe as my OAuth client framework.  It's really simple to use, and I was able to implement an OAuth client in about 4 hours with several interruptions included in that time.

Because both the OAuth client and the provider have to go through many of the same steps to verify a request, I wondered how difficult it would actually be to create a provider on my own.  So I decided to figure out how to take Scribe and use it to create an OAuth provider implementation.  I spent a good part of the day understanding the Scribe internals.  It's pretty clean code, and I found that I could reuse quite a bit of it to create the provider side.  One of the reasons I decided to stick with Scribe was because it was very light-weight.  Even so, like all gems there's quite a bit of capability if you look deep enough.

About halfway through this exercise, we had the ABBI Pull call, and several folks had raised concerns about OAuth and the effort their clients would need implement it instead of some other framework for accessing patient data.  For a lot of good reasons, I don't trust code not developed by security experts to secure my information.  OAuth has a lot of features that I understand to secure a connection.  Some OAuth-like structure that works in different ways with different sites just doesn't cut it for me.

So, yesterday's discussion about the access framework for ABBI reassured me that understanding how complex it would be to implement OAuth starting with just what I know, and a few additional tools, would probably be a good idea.

Today I'm about halfway there.  Having the client implementation helps, because it becomes part of how I test my implementation.  I did my original tests with ABBI using Twitter as my OAuth provider.  What I now needed to do was develop an OAuth provider implementation that I could direct ABBI at instead of Twitter.  Once that was able to complete the workflow correctly, I knew I'd be done.  I've completed testing about half the workflow.

I should be finished with the provider tonight, and I'll post about how it works tomorrow, along with the source code for anyone else who might be seeking a Java OAuth provider.  I expect that it will be fewer than 500 lines of code.  It won't be production code, in that it won't have all the cool enterprisy stuff like user creation and management, access controls, persistence, et cetera that you need for a full blown authentication server.  What it will have is the stuff you need to integrate what you already use for those things with OAuth, so that you can authorize other applications to access data via your application API.

-- Keith