Windows Live ID Authentication for your Azure Web Site, Part 1

One of the many services made available to your Azure web applications is the ability to authenticate using Windows Live ID. This is an attractive alternative to forcing the user to create and remember yet another user id and password. You can also wire Live ID in to non-Azure web sites, but in this article we're going to focus specifically on how to Live ID-enable your Azure web application. In Part 1, we'll describe the user experience and the page flow model for Live ID authentication. In Part 2, we'll see what this means in code.

For an Azure web application, Windows Live ID authentication is based on 3-way cooperation between your web site, Windows Live ID, and your Azure project settings.

User Experience and Page Flow

The first thing to understand is the intended user experience. Let's walk through it from the vantage point of a web visitor to your Azure-hosted web site.

1. On your site, not signed in

When a visitor first comes to your site, your site likely won't know who they are unless they've been there very recently. Your site will offer a Sign In link (click the image for a larger view).



2. Live ID sign in

When the user clicks on your Sign In link, their browser will take them to the Windows Live ID system, where the user can sign on with an existing Windows Live ID or create a new one on the spot. Don't worry, you haven't lost the user as you'll see in a moment.




3. Back to your site, authenticated

Upon successful sign in to Windows Live ID, transfer is passed right back to your site. This time, the site knows who you are and is able to read account-specific information from cloud storage. Instead of "Sign in please", the site now welcomes the user with a cheery "Welcome, [Name]!"



Pretty cool, eh? Now let's see just how this magic is made to happen.

Page Flow

Now that we know what the experience is like, let's study the page flow from behind the scenes. Although the user experience seems to involve 3 pages, there are in fact 4 page states to consider as shown in the figure below.



Here's a blow-by-blow account of what happens.

1. On your site, not signed in

When a visitor comes to your site, your site may or may not know who they are. This is determined by a cookie. You include the Live Services IDLoginStatus control on your page, which displays a Sign In link if your Live ID identity is unknown to the site. if it does know who you are, the control will instead display a Sign Out link. Let's assume for the moment we don't know who the user is and the cookie is not found.

In the screen capture below, my site recognizes it does not know who the user is and alters the page display accordingly. This is evidenced by the "Please sign in with Live ID" message (set by code in my Page_Load method) and the Sign In link (provided by the IDLoginStatus control). Note you can control the appearance of the control to match your site's look.

2. Live ID sign in

When the user clicks the Sign In link, the IDLoginStatus control redirects the browser to the Windows Live ID system, where the user can sign on with an existing Windows Live ID or create a new one on the spot. Note the Windows Live ID infrastructure is only willing to participate if your site has been previously registered with it.

3. Authentication Handling

This next step is not apparent to the user but is an integral part of the process. Upon successful sign in to Windows Live ID, transfer is passed back to your site--but not to the originating page. Instead, a web authentication handler page is invoked. How does Live ID know where to direct control? You set up a "return URL" when you register your site with Live ID. Your web authentication handler page is given a unique ID (GUID) for the user and a cookie is created. This GUID is the key you use to provision account-specific data for the user.

4. On your site, signed in

The handler then redirects to the desired page. In this example, we go right back to the page we started on, Default.aspx. This time, the cookie exists and the site is able to read account-specific information from cloud storage keyed on the unique ID of the user we received in Step 3. Instead of "Sign in please", the site now welcomes the user with a cheery "Welcome, [Name]!"

That's what will happen if the user is a return visitor to your site, but what if it's a brand new visitor? In that case you won't find anything in cloud storage keyed to the user GUID and you can take an alternative action, such as welcoming the new user and directing them to set up a profile.

That's the deal, from a page flow standpoint. All we need to do now is get into the code. In Part 2, we'll show you how to implement this for yourself.