I don't know about you, but for me, the world would be a better place if I could use just one pair of credentials for everything. Of course, using the same username and password over and over again is not a recommended practice, but that doesn't mean I can't wish for it. And I'm not alone. For this reason, more and more websites are offering a one-click sign-in approach. "Lazy authentication" means that a website relies on the response it gets from some external service. When you implement this type of authentication, a user who successfully signs in on the companion service site is automatically authenticated on your site as well. This is an idea that Microsoft attempted to promote years ago, with its Passport initiative. For some reason, the solution didn't live up to expectations and the initiative never caught on. Today, the Passport API is officially obsolete, but its core idea is more alive than ever.
In this article, I'll show how to enable an ASP.NET MVC website to authenticate users via Twitter. Instead of (or in addition to) providing classic membership-based authentication, the site will allow users to authenticate with their Twitter accounts and to connect automatically to the site if they're already logged on to Twitter.
OpenID vs. OAuth
If you're looking for a better (and more open) version of Passport, then consider the OpenID protocol. You can find out all about OpenID at openid.net. This protocol has just one goal: identifying users in the simplest possible way. A website that acts as an OpenID client simply needs a username; the website that acts as an OpenID server holds the username and password only. No other user-specific content or information is supposed to exist or be shared.
The main purpose of OpenID is to make access to a website easier, quicker, and more agreeable for end users. The visitors to sites that support OpenID can sign in by using an existing identity token that another site has issued. An OpenID–enabled website authenticates its users against an external identity provider and doesn't need to store passwords or implement a membership layer.
The advent of social networks has changed the situation. Not only do users want to use a single and familiar identity to connect to multiple sites, but they might agree to grant one website access to some resources that they manage on another site. OAuth (see oauth.net) is another single sign-on (SSO) scheme with more capabilities than OpenID. A website that acts as an OAuth provider operates as an identity provider; when users log in, the site allows them to specify permissions on its resources. A website that uses OAuth authentication acts as the client of an OAuth provider. Two popular OAuth providers are Twitter and Facebook.
The DotNetOpenAuth Library
You can write your own implementation of the OpenID or OAuth protocols, but using a made-to-measure library enhances your productivity. Implementing OpenID or OAuth is mostly a matter of HTTP programming—calling a given URL, preparing a query string, parsing the response, and so on. These tasks are doable but involve many pesky details. Quite a few good libraries exist to help integrate OpenID and OAuth into your websites. A popular library for Microsoft .NET developers is DotNetOpenAuth (DNOA), which is also available from as a NuGet package (as Figure 1 shows).
Figure 1: Getting DotNetOpenAuth from the NuGet manager
The library comes with a companion assembly—the DotNetOpenAuth application block—that contains some useful helper classes, including one that is prepackaged for Twitter. This class basically makes it quick and easy to implement a Twitter-based SSO for every site.
Let Twitter Know About You
An OpenID provider is uniquely identified through a URL, and all you need to do is prepare a call with the proper number of parameters. But when it comes to OAuth, you need to take a preliminary step: registering your website with the OAuth provider application. The details might differ a bit from provider to provider. For example, Facebook requires that you add the Developer block to your personal profile and set up a new application through that block. Registering an application involves providing a name, an icon, a URL, and contact information. For Twitter, the process is simpler. You go to dev.twitter.com, register a new application (site or desktop) and enter a few details, as Figure 2 shows.
Figure 2: Registering an application with Twitter