Monday, 19 August 2013

Building a ServiceStack-based OAuth2 resource server using DotNetOpenAuth

Last week, I asked on StackOverflow if anyone had used DotNetOpenAuth to secure a ServiceStack API using OAuth2. Well, it would appear not… so alongside a week of band rehearsals and a big old party last weekend, I’ve put a proof of concept up onGithub that demonstrates how to use ServiceStack and DotNetOpenAuth together to create a REST API that’s secured using OAuth2. The app I’m working on is aimed specifically at existing customers, who will already have a login account on our site, so I don’t need to use OpenID at all. In fact, I spent a good few days puzzling over this before I realised my mistake. After digging through the various specs and innumerable blog posts, I decided to use the OAuth2 authorization framework – specifically, a feature of that framework called the resource owner password credentials grant

The DotNetOpenAuth project includes a couple of great OAuth2 samples, including an authorization server (the bit that does the customer login), but they’re built primarily around ASP.NET MVC or WCF. I’ve worked with both of these in the past, but recently I’ve switched to using the ServiceStack library to build ReST APIs, and I absolutely love it. It’s easy to use, easy to extend, and wonderfully lightweight, so I wanted to use ServiceStack to build the data API that our app is going to use. I assumed it wouldn’t be too hard to build our own authorisation server, and then use a standard protocol like OAuth to control access to the resources exposed by this server.

There’s a working prototype / proof of concept up on GitHub now, at https://github.com/dylanbeattie/OAuthStack – complete with commentary on how the various integration points worked. OAuth2 is actually conceptually quite simple, but getting the two libraries to work together proved a little fiddly; both ServiceStack and OpenAuthDotNet use their own abstractions over the ASP.NET request/response objects, making me really wish Microsoft hadn’t made the .NET HTTP framework quite so inflexible back in the day… but after a week or so of tinkering, testing, poring over RFCs and bouncing around in the Visual Studio debugger, I’ve got something that seems pretty lightweight, doesn’t reinvent the wheel, and seems to satisfy the requirements.

Suffice to say that if DotNetOpenAuth and ServiceStack weren’t open source this kind of integration would have been practically impossible, so I want to say a huge thank you to the authors and maintainers of both of those projects. Thanks, guys. You rock :)

4 comments:

Joe said...

Very cool. Thanks for doing this and sharing your code! I will look into the using this for a side project of mine.

Ygor Mutti said...

Hi Dylan,

I've faced the same situation you describe in the beginning of the post. I tried to use DotNetOpenAuth, then I decided to "reinvent the wheel". The reasons were:

- I'm not familiar with MVC and didn't want to add another library to our stack;
- DotNetOpenAuth resource server features lack documentation (at the time there was one sample, one flow, nothing else)
- Also, as you say, OAuth is pretty simple. That lead me to think that implementing an OAuth 2.0 framework on top of ServiceStack would be more productive than spending time with DotNetOpenAuth.

Then I've read about your prototype by reading a post on ServiceStack G+ group, and it made me think I need to take a closer look at DotNetOpenAuth. I think that I'll stick to my implementation, but I got curious...

Do you think your prototype can be easily extended to support other flows? (I basically need all the flows)

And do you know if it could support random opaque tokens? (I mean tokens that don't encode any information, encrypted or not) I want to validate the tokens against the database instead of using JSON web tokens.

Thank you!

Ygor Mutti said...

Hi Dylan,

I've faced the same situation you describe in the beginning of the post. I tried to use DotNetOpenAuth, then I decided to "reinvent the wheel". The reasons were:

- I'm not familiar with MVC and didn't want to add another library to our stack;
- DotNetOpenAuth resource server features lack documentation (at the time there was one sample, one flow, nothing else)
- Also, as you say, OAuth is pretty simple. That lead me to think that implementing an OAuth 2.0 framework on top of ServiceStack would be more productive than spending time with DotNetOpenAuth.

Then I've read about your prototype by reading a post on ServiceStack G+ group, and it made me think I need to take a closer look at DotNetOpenAuth. I think that I'll stick to my implementation, but I got curious...

Do you think your prototype can be easily extended to support other flows? (I basically need all the flows)

And do you know if it could support random opaque tokens? (I mean tokens that don't encode any information, encrypted or not) I want to validate the tokens against the database instead of using JSON web tokens.

Thank you!

Shahana Shafiuddin said...

Nice description.