OMG it’s OWIN
I have recently started work on an exciting new project that saw me unshackled from the confines from a CMS. Free as a bird, I’ve delved head first into the new world of Visual Studio 2013, .NET 4.5, EF6 and MVC5... OMG I’m loving it.
The first new feature I learned of was Microsoft’s new authentication provider with the Identity model architecture, which led me into learning about OWIN. OWIN – the Open Web Interface for .NET – is a new industry specification outlining a standard interface between .NET web servers and applications, primarily authored by developers of the ASP.NET team. The purpose of OWIN is encourage the development of modules that serve the goal of bridging this server-application divide. One such example is SignalR, a framework that has been around for a while now, that allows a developer to create real-time client side updates from server-side applications – but the real highlight is that it can communicate with multiple connected clients at once. For example, you could create a Skype-style chat system with SignalR.
What I found most exciting about the OWIN modules that came pre-loaded into a new MVC5 application were those that directly helped me with my new project requirements – those that integrated with the new Identity security model. The new model is worthy of a blog itself, but I wanted to bring attention to the OWIN modules used for connecting external authentication systems, such as Facebook.
One aspect of developing websites I always groan about is when I see the little Facebook Connect (or Google+, or Twitter..) login icons on a prototype. “This way lies madness” I think to myself, as I imagine configuring convoluted JavaScript libraries or no-longer-maintained .NET wrappers to allow users to skip regular registration via a form. Every time I do one of these implementations I find that the architecture has moved on another point release and I have to work out how to do it all again.
By default, a newly created MVC5 application with Bootstrap has the Identity security model configured and ready to go. Unfortunately for those of us who prefer database-first development it appears locked to code-first development (if there is a clean way around this, I haven’t found it yet) but that aside the convenience of having all your security taken care of almost automatically is far too enticing to ignore.
In your /App_Start/Startup.Auth.cs you may already find this code commented out:
You can already see how simple this will be. By un-commenting the app.UseFacebookAuthentication code and providing your Facebook application’s ID and Secret code, you have instantly enabled Facebook authentication for your website. In the example Bootstrap site, a Facebook button has appeared in the Login/Register form that works as you would expect. Pressing it redirects you to facebook.com where you must login then agree to the connection, before being redirected back to your Bootstrap site where you can complete the signup form. The code can be expanded upon to request higher permissions from the user, and also store the returned information as Claims (see ‘further reading’). By default, all data for authentication is stored in the automatically-created Identity database tables for User, UserRoles, UserLogins and UserClaims.
My site required authentication via Facebook, Google, Twitter and LinkedIn. The default implementation does not include LinkedIn, but remember that OWIN is modular and that means that there is a good chance somebody has already written a module and included it as a NuGet package. Search for “Owin.Security.Providers.LinkedIn”, install it in your website and add and configure this instantiating code, again to Startup.Auth:
You have now enabled authentication with LinkedIn.
For further reading: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana and http://www.theroks.com/social-login-owin-authentication-mvc5/
