Some of you may have already heard the announcement on .NET Rocks (time index 41:30), but in case you haven’t: Visual Studio 2012 will include DotNetOpenAuth in all its ASP.NET project templates. Woot! Yes, my friends, it has finally happened.
Q&A
Q: With the announcement, Scott Hunter mentions being able to hack into a site that accepted Twitter logins, and may have suggested that the site used DotNetOpenAuth. He also mentioned that Microsoft “hardened” the library to fix some security issues. Does DotNetOpenAuth have security holes?
A: Please don’t be alarmed. I worked closely with the Microsoft ASP.NET team who added DotNetOpenAuth to VS2012, and they never found any security holes in the library. I don’t actually know what Scott is referring to here. Since a web site can certainly use DNOA improperly, security holes in web sites certainly are possible, but not likely from a fault in the library.
Q: Is DotNetOpenAuth a Microsoft project now?
A: No. DotNetOpenAuth continues to be independently owned and developed, although Microsoft has begun making source contributions to it. Another example of this is jQuery, which Microsoft ships with ASP.NET as well, but Microsoft doesn’t own or directly control it.
Q: Will DotNetOpenAuth continue to get regular releases, or are they now tied to Visual Studio releases?
A: DotNetOpenAuth will continue to ship independently of VS. The copy of DotNetOpenAuth that ships with Visual Studio 2012 is actually one of DotNetOpenAuth’s own past releases. The way the ASP.NET project templates bundle it is as a NuGet package, so if you create a web project based on these templates, NuGet can help you upgrade to the latest version of DotNetOpenAuth right away.
Q: Is Microsoft contributing to DotNetOpenAuth now?
A: Yes. You may have noticed the new DotNetOpenAuth.AspNet package available on NuGet. This is Microsoft’s contribution to the DotNetOpenAuth library. Whereas the rest of DotNetOpenAuth is strictly a protocol library (no specific APIs for individual popular online services), the DotNetOpenAuth.AspNet package adds an assembly which does target all the popular identity providers explicitly, making it easier to add buttons for “log in with Google”, “log in with LinkedIn”, etc.
Q: What is DotNetOpenAuth.AspNet?
A: DotNetOpenAuth.AspNet is Microsoft’s front-end to DotNetOpenAuth that the ASP.NET project templates use instead of DotNetOpenAuth directly. Internally, DotNetOpenAuth.AspNet uses DotNetOpenAuth so you’re still using the time-tested library underneath. So if you create a new ASP.NET project in VS2012, you’ll be able to switch on DotNetOpenAuth.AspNet by uncommenting a few lines of code.
Q: How does DotNetOpenAuth.AspNet compare with the core DotNetOpenAuth library? Should I switch my existing code to use DotNetOpenAuth.AspNet?
A: To keep things simple, the ASP.NET team decided to conceal the core DotNetOpenAuth API behind theirs and they set several DotNetOpenAuth settings to their simple or “stateless” mode values. This means that things are more likely to work in web farms right out of the box if you’re using the DotNetOpenAuth.AspNet frontend, at the cost of a slightly less secure set of defaults. Some settings are harder to reach if you’re using the DotNetOpenAuth.AspNet frontend. If you have existing code by all means keep it. The library you’re using is still active developed and what DotNetOpenAuth.AspNet uses behind the scenes so you’re by no means going to be using obsolete code in the foreseeable future. If you’re writing new code, DotNetOpenAuth is still a fine choice, but if you’re just acting as a relying party and want a simpler API to use against only popular identity providers, then DotNetOpenAuth.AspNet is a reasonable choice.
Q: How else is DotNetOpenAuth.AspNet different than the rest of the library?
A: It is less configurable than the rest of the library. In particular it doesn’t offer any way to be configured via your web.config file. Although since the core DotNetOpenAuth is still active underneath the API, the normal web.config settings you use for DNOA may still apply in some cases. Also, I don’t actively support DotNetOpenAuth.AspNet myself. Any feedback or issues filed against it I forward to the ASP.NET team, who maintains that project.
Q: So… this is a Good Thing, right?
A: Absolutely. It has never been easier for ASP.NET developers to build web sites that delegate authentication responsibilities to popular identity providers. This is a boon for web developers, and especially a boon for all our web visitors out there that are now more likely to be able to reuse a few Internet identities instead of maintaining dozens of accounts on all the web sites they visit.
I am trying to create a new MVC Web API project in VS 2012 pro. I am not seeing the DotNetOpenAuth dlls in my references. Do I need to include them separately?Thanks much for the article!