LiveID, authentication and the cloud

I would imagine that by now, most people who use Windows (and other operating systems), would have signed up for a LiveID. This is the mechanism that Microsoft use just about everywhere they need to authenticate users on the web. You may have noticed that LiveID accounts can be used on non-Microsoft sites as well.

In this post I wanted to summarize some of the scenarios for using LiveID, and illustrate its usefulness as an authentication mechanism.

• From a user’s perspective, having to remember a single id and password for a whole lot of sites is convenient. Sometimes a user even **appears** not to have to log in at all, because their credentials are remembered for them.
• From a developer’s, having someone else look after the authentication process can dramatically simplify an application.

The scenarios I’d like to outline are:

1. Logging in directly to a LiveID enabled application. Examples include Windows Live Messenger, or Live Mesh.
2. Using delegated authentication. Your application needs to use a resource in another LiveID enabled application.
3. Using persistent delegated authentication. Your application needs to use a resource in another LiveID enabled application, but you don’t want to keep asking the user for their credentials.
4. Using LiveID as the authentication mechanism for your application.
5. Using a LiveID to authenticate against an OpenID enabled application.

I’m sure there are plenty of other scenarios, but these 5 strike me as the most interesting and useful in practice.

Scenario 1 - Logging in directly to a LiveID enabled application

The most trivial version of this (from a user’s point of view) is logging in to an application like Windows Live Messenger or a protected page somewhere on microsoft.com. Once the user has registered for a LiveID, they can log in anywhere they see the LiveID login logo.

A slightly more complex version of this scenario (for a developer) would be logging in from within a web application.

var accessOptions = new LiveItemAccessOptions(true);
NetworkCredential credentials = new NetworkCredential(userName, password);
LiveOperatingEnvironment endpoint = new LiveOperatingEnvironment();
var authToken = credentials.GetWindowsLiveAuthenticationToken();
endpoint.Connect(authToken, AuthenticationTokenType.UserToken, meshCloudUri, accessOptions);
Mesh meshSession = endpoint.Mesh;
HttpContext.Current.Session["MeshSession"] = meshSession;

The code above logs a user on to the Live Mesh Operating Environment, using the id and password provided by the user. Presumably here, the endpoint looks after the authentication process for you. After that the web application is caching the authenticated Mesh object for the duration of the user’s session.

The significant feature of this scenario, is that all the interaction with LiveID is handled by someone else – in this case the Mesh Live Operating Environment.

Scenario 2 - Using delegated authentication

This scenario differs from the first in that your application needs to authenticate with LiveID **before** accessing a resource. For example, you might have a web application that enables a user to send and receive instant messages from within the application. In this case your application will have to log in to Windows Live Messenger on behalf of the user, hence delegation. You also want the user to have to provide their credentials once per session, so they don’t keep getting prompted to sign in!

Assuming the user already has a LiveID, this scenario breaks down into two major steps:

1. The user must give their consent for your application to access their Live Messenger account. Ideally this happens only one, or at least infrequently (once a month?).
2. The user logs in at the start of their session, and your application can then send and receive instant messages for them during the session.

The consent phase

Here the user is giving consent for this **specific** application to have permissions to access their Live Messenger account for some period of time.

1. Your application must be able to uniquely identify itself – so you must register your application on the Azure Services Developer Portal and get some identifying codes.
2. Your application must redirect the user to the LiveID consent webpage (passing your app’s unique identifying codes) to allow the user to give their consent.
3. Your user will be automatically redirected back to your application after giving consent. Also, LiveId will return a consent token (see below) in a cookie to your application.

All of these interactions are, of course, encrypted.

The user uses your application

This is where the delegation occurs – your application can use Live Messenger on behalf of the user.

1. Once the user has authenticated using LiveID, the LiveID servers return an encrypted cookie called a consent token (if the user doesn’t already have one from the consent phase). This consent token contains, amongst other items, a delegation token and some expiry details. The consent token is potentially a long-lived token (there is also a renewal/refresh mechanism that I won’t go into here).
2. From this point on, whenever your application needs to interact with Live Messenger, it will send the signed delegation token back to the server.

Once the user logs off, the two tokens are lost, so when they go back to the site they’ll have to log in again and get a new consent token. To avoid replay attacks, the delegation token is signed and datetime stamped.

Scenario 3 – Using persistent delegated authentication

This scenario is very similar to scenario 2. In scenario 2, each time the user uses your application, they have to sign on again to get access (in this example) to the messenger functionality. If your application can cache the consent token, perhaps in a database, then there is no need for the user to have to log on because the delegation token can be re-signed and sent. The only time the user might have to sign on again is to refresh the consent token when it expires.

This approach leads to a much better user experience, but you do have to have a secure way of storing the consent tokens.

Scenario 4 - Using LiveID as the authentication mechanism for your application

The first three scenarios are all using a LiveId as way of authenticating against an existing (Microsoft) application or resource. There is nothing to prevent you from using LiveId as your own application’s authentication mechanism. This has a number of advantages:

1. You don’t have to go through the hassle of designing your own authentication system, and implementing databases to store userids and passwords etc.
2. The user doesn’t have to remember yet another userid and password.
3. You have a a tried and tested authentication scheme.

This scenario is again, very similar to scenario 2. You need to register your application on the Azure Services Developer Portal and obtain your unique identifying codes. The Live SDK includes a set of web controls that will simplify the task of building your UI and handling the various tokens and cookies.

Scenario 5 - Using a LiveID to authenticate against an OpenID enabled application

OpenId is an interesting approach to try and provide a framework where a user might need just one online digital identity, instead of the dozens of userids and passwords most of us currently have.

An OpenId provider enables users to create a digital identitiy (ie create a userid and password). The OpenId provider also validates identities on behalf of other sites. So, for example, if I want to use a site like Stackoverflow, I will need an OpenId. When I visit Stackoverflow, it needs to know who I am, so it asks me for an OpenId. I am then redirected to my OpenId provider where I enter my password, and if it’s correct I’m redirected back to Stackoverflow. Stackoverflow knows who I am, without even having to see my password because it trusts the OpenId provider to authenticate me.

Microsoft currently have a beta version of LiveId working as an OpenId provider. So, if you want your digital identity to be your LiveId, that’s now possible. Of course your could select a different OpenId provider if you preferred.