The next major release of DotNetOpenId, slated for a release in or around March 2009, will add OAuth support to the mix.  If you don’t know what OAuth is, it basically provides a way for your site’s visitors to authorize your site to download their email address book without giving you their email address and password.  It’s of course much bigger than that, but that’s the easiest way to start thinking about it.

A little history of the last several months

The DotNetOAuth library that I started a few months ago has come a long way. Its purpose was to be a sandbox to author a new user agent redirect-based messaging framework that would serve OAuth, OpenID, and any similar framework for the future. The framework’s charter included being easy, maintainable and discoverable, and very unit testable.

The framework’s first application was an implementation of the OAuth protocol (thus the DotNetOAuth library name). Then I added OpenID support to DotNetOAuth, porting a few files from DotNetOpenId but mostly rewriting it all from scratch in order to take advantage of the new messaging framework. Today DotNetOAuth can do OAuth (both Service Provider and Consumer roles) and OpenID (both Provider and Relying Party roles) and I’ve ported the samples from DotNetOpenId over to DotNetOAuth and they work great.

This marks an important milestone for both DotNetOpenId and DotNetOAuth.  DotNetOpenId has a lot of experience out in the wild and little changes here and there to cooperate with various systems has already been made.  DotNetOAuth had the new messaging framework and added support for OAuth.  It makes sense (and in fact was part of the initial vision of what this might evolve into) to merge the two libraries so we can capture the benefits of both.

A new name for DotNetOpenId

With this merge comes a new name for the library: DotNet(OpenId) + DotNet(OAuth) = DotNetOpenAuth.  The name reflects the new capabilities of the library, and the technologies it may incorporate in the future.  Future directions may include Shibboleth, InfoCard, and the Next Big Thing for authentication and/or authorization, whatever that may be.  DotNetOpenAuth is the library to build up protocol implementations for .NET.  It is licensed under the Microsoft Public License (Ms-PL), which is a very liberal open source license that allows the software’s royalty-free use in both open source and closed source applications.

Why the new name?  That was a hard decision.  DotNetOpenId has quite a following already and there was some incentive to keep the name and leverage the momentum.  On the other hand, we want people looking for OAuth support to not pass by DotNetOpenId without considering it because of its name.  In the future we want to incorporate new protocols as well which will continue to make OpenId just one of many features the library offers.  So in the end, and after talking to Scott Hanselman and Jason Alexander about it (and getting agreement in the problem, and differing suggestions as to the proposed solution), I decided to go ahead and change the name for this major release.

In its first release(s), DotNetOpenAuth will offer an easy upgrade path for users of the DotNetOpenId v2.x releases by including the old namespace and classes in the assembly so that the new library can be dropped in and used immediately, giving webmasters the choice of when to update their code to call the new APIs.  Let me know what you think of this idea as I haven’t written these shims yet and so feedback on whether you need this would be very helpful!

What about DotNetOpenId 2.x?

Thousands of you are already using DotNetOpenId 2.x.  What does this mean for you in terms of the work necessary to upgrade to the new version?  More than usual, but not a whole lot.  First rest assured that due to its maturity and popularity, support for DotNetOpenId v2.5 (and perhaps even a v2.6) will not be cut off immediately upon the release of v3.0.  I expect to respond to bugs filed against the v2.5 versions for several months.

And when you decide to make the upgrade to v3.0, I’m working to ensure the transition will be as smooth as possible.  Although v3.0 has an all new “DotNetOpenAuth” namespace, the public API for OpenID in that namespace is very similar to the old ones in the DotNetOpenId namespace so it may be as easy as updating your “using” line in C# or “Imports” in VB.NET.  Depending on the features you were using you may have a little more work to do to get your code to compile.  Watch for a follow-up post describing the new object model and why I think you’ll like it much better than the old one even though on the outset it looks so similar. 

If there is sufficient demand for it, I’ll add a set of shims in the assembly with the old namespace so you can use all your existing code with the new library and have it Just Work.  Let me know whether you feel this feature is worth the effort.  Leave a comment, or email

Where can one download the new version?

The v3.0 release is slated for a March 2009 release.  But watch this blog or the dotnetopenid mailing list for an announcement about the Beta 1 release in the next few days.  Of course it’s all open source, so you could download the source code to it now, but I recommend you wait a few more days so you can see it in digital shrink wrap.

7 thoughts on “DotNetOpenId v3.0 to feature built-in OAuth support”
  1. I could not get your samples to compile. I am getting a Error 1 The type or namespace name ‘log4net’ could not be found (are you missing a using directive or an assembly reference?) error.

  2. Hi Zaske,

    In an effort to reduce the download size of the zip, I removed log4net.dll and dotnetopenauth.dll from each web sample’s bin directories. But I left .refresh files in the bin directories pointing to the locations where those .dll’s can be found within the zip, so I think if you build the samples solution within Visual Studio it should work. If not, you can manually copy the .dll’s into the web site’s bin directory.

  3. There seems to be no way to turn off the log4net output from your dll, except to turn it off for the entire website. There should be (perhaps there is) a configuration option in the web.config file to disable the log4net output from the dll.

  4. Unfortunately, you have bound the dll to the log4net version 1.2.10 signed dll, so your dll will not run on any site which uses a different version, or a custom build, of log4net. This make it unusable for a large percentage of websites.

    Can you please releases a version of the dll which will run with ANY version of log4net, or remove the log4net dependency entirely.

    Thank you.

  5. Very good point. While DotNetOpenAuth doesn't require log4net.dll to be present, IF it is present, I recently noticed that as you said, it insists on a specific version of log4net and this is very annoying. I've opened Ticket 86 to track this.

Comments are closed.