In choosing an implementation of OpenID for your .NET web site, of course I would have to recommend DotNetOpenId, seeing as I spend a considerable amount of my spare time working on it. But Samuli (in the comments on Troy’s recent blog post regarding OpenID) recently asked me to give a sales pitch for DotNetOpenID over another implementation called ExtremeSwank.
First I want to make clear that I respect John Ehn (of ExtremeSwank) and his very dedicated work to his library. He has no doubt spent countless hours and published all his work as free open-source software, for which he is to be commended.
On with the sales pitch… (I’ll abbreviate to ES and DNOI to refer to the two libraries)
- DNOI supports Providers and Relying Party web sites. ES only supports Relying Parties.
- DNOI has several ASP.NET custom controls built-in that make relying party and provider scenarios very easy, should you choose to use them. (Please note that the ASP.NET controls are not required, and that the API-level OpenID support is still simple to use.) ES has a couple of web user controls which simplify its API, but have to be copied into the hosting web site as source code — since there’s a bucketload of code in the code-behind for these controls, that’s difficult to maintain with each successive version of the library for consumers to hand-upgrade in their web sites.
- DNOI doesn’t require an ASP.NET HttpContext, allowing all OpenID handling to be done on a backend server (useful for web farms). ES requires the HttpContext, apparently disallowing this.
- ES doesn’t have any unit tests while DNOI has well over 100 to verify proper function and resistance against security exploits.
- DNOI has been much more widely adopted, and therefore tested in the field.
- DNOI has already been deployed on many shared hosting environments, and even web farms successfully.
- DNOI has been scrubbed for public classes/members to minimize surface area for simple Intellisense discovery of how to use the library, for fewer breaking changes going forward, and for security. It seems ES still has way too many classes marked Public.
- DNOI is prepared for future versions of OpenID (by abstracting away most of the protocol version differences in a dedicated class) so we should be able to rev for the next version quickly.
- DNOI is prepared for localization (all our human-readable strings are in a resource file), and we’ve already had a volunteer to begin translation into at least one other language. [27Apr2008 Update: John of ES points out in comments below that ES is also localization ready in that it doesn’t return or throw any strings at all — just an enum so that the site author can provide the text to display.]
- DNOI’s approach to OpenID has been to implement the spec fully and to the letter so that we interoperate with all (so far) OpenID web sites, whereas ES’s change history is ridden with ‘now works with aol, … now works with claimid, … now works with ___….’, which suggests to me that it’s a gradual hit-or-miss thing. ES also has a Quirks class that special cases interop with certain other web sites in order to work with them. DNOI hasn’t needed a Quirks class (at least not yet) because our implementation of the spec works with everything people have tested against. Now maybe there’s a history behind the Quirks class and those other web sites were not implementing the spec properly but now are… I don’t know for sure. But I know DNOI doesn’t have a class like this and works with all the sites ES mentions in its Quirks class.
There is one area where I bow to ExtremeSwank’s better coverage. While DotNetOpenID supports extensions in an extensible way (that is, you can use any extension you want with it), it currently only comes prepackaged with support for Simple Registration, leaving any other extension to have to be hand-coded by the hosting web site. The difficulty of this depends largely on the complexity of the extension you want to use. ExtremeSwank apparently has built-in support for several extensions out of the box including Simple Registration, Attribute Exchange, and Authentication Policy. I expect DotNetOpenID to develop these extensions as standard offerings soon though, so this doesn’t bother me too much.
Please note that while I’ve glossed over the ExtremeSwank codebase a couple of times, especially in writing this post, I have not ever used it in production. While I believe what I’ve written above to be correct, if someone finds something I’m mistaken about please comment and I’ll be happy to make note of it. This post is as-of today however, so if some of these things get fixed later, kudos to ExtremeSwank, but I’ll leave the post as-is.