Are You Ready for Live ID?

Communism doesn't work because people like to own stuff. - Frank Zappa

Microsoft has rolled out its Live ID Web Authentication SDK and from some of the forum posts I've seen, developers are already misunderstanding what they really have to work with. You see comments like "hey, but it won't give me their email", or "Useless!", etc. Wrong!

Windows Live ID is the authentication used by Microsoft’s web sites and services - for example, Hotmail and Live.com. Windows Live ID is the evolution of the original Passport Service -- the name change ostensibly to focus on Window Live services and its ability to federate in a multi-property, multi-service identity world. If you don't believe this is big, let me give you one number: currently, more than 380 million users have credentials that work with Windows Live ID. D00d, that -- is big!

Oh, and by the way - it's not just for the web. There is also a Windows Live ID Client SDK.

Mostly the offering has been driven by MS Identity Guru, Kim Cameron, with the idea that there is a “metasystem” that utilizes WS-Trust to translate tokens, so that all identity systems can interact with each other. This is all web standards -- isn't that the direction that everything is supposed to be going? I'm not so sure that Google and Yahoo, with their authentication schemes and API's, are getting this...

Frankly, I think it is deplorable that Microsoft took so long to "get it" - and to finally do this. However, it now appears that Microsoft has indeed "got it" -- and that the commercial competitors have actually gone backwards in that they "do not".

The most important aspect of this rollout is that Windows Live ID will support WS-Trust, WS-Federation, CardSpace and ADFS (Active Directory Federation Server). This means that Windows Live ID can interact with other identity implementations and that you can integrate your corporate Active Directory environment into Windows Live ID. In other words, what was once a closed system (Passport) has now been transformed into an open, standards -based, transparent system.

When you put the sample IFRAME - based Live ID sign-in "control" on a page, and a Live ID user "signs in", the AppId information you've stored when you registered your property (site) with LIve ID tells it to redirect to the page you've designated. At this point you can capture the unique UserId string for that user, which will always be the same for your application. Now this requires a bit of thinking "outside the box" for most developers.

Normally, you would have a new user create a membership - with their username, email, password, etc. Your membership provider would store this information and this would enable the user to come back and log back in at your site. You would probably email them a link to "activate" so that you don't get "spambers". You would authenticate them via the username and password they provide. With Live ID, it is reversed just a bit. A new user signs into your site with their Live ID and -- THEY ARE ALREADY AUTHENTICATED -- you just don't have their user information yet. So, what you do is look up their UserId (their Live ID identifier described above) and if they aren't in your system, you take them immediately to your sign-up form where they can now enter their name, email, preferences, etc. For standard ASP.NET Membership provider authentication, the password you would use would the same as the username, and that is the unique user ID string returned from Live ID (it's a GUID).

This is then stored in the database using the UserId you got from the Live ID sign-in as the "Lookup" to get the member info back out when they revisit. Since this information is stored in a cookie, they can have a persistent, seamless login using the all - familiar Live ID mechanism. If your user doesn't want to provide the required Membership ("registration") information, then they may be able to authenticate with Live ID, but it is up to you whether you want them to have full "User" privileges.

This is very easy to do with the standard ASP.NET Membership Provider implementation by writing a custom Membership Provider class and using the UserId string to do the ValidateUser work. You don't really need a password, since your user is already "legit" from Live ID. In fact, you don't even need to use the membership provider - you can just do a database lookup from your own non-opaque Users table.

What's the downside?

The downside is that you've relegated your authentication process to an outside mechanism that you don't control. What if it is very slow (it is known to be so, occasionally)? What if it simply goes down for an extended period? I've had trouble accessing my Live SkyDrive folders account for several days - all I get is an error page. Not good. Maybe the best compromise is to use Live ID as I've described but also allow for your regular sign-in mechanism as a "fail safe". Again, not very difficult to implement.

I humbly predict that as soon as developers start to "get it" with Live ID and CardSpace integration (already available in Beta) you are going to see some major, major changes in how web sites authenticate their users. There's already a Mozilla CardSpace extension for Firefox, and whether you understand it or not, CardSpace is going to be very big. It is already supported with OpenID. Combine it with Live ID and I say you've got a real win-win for everyone.

The Live ID SDK has downloadable sample code in ASP.NET (C#), Java, Perl, PHP, Python, and Ruby. Right now the documentation terms of service says you can have 1 million authentications without any fees.

N.B. I've now added an article with downloadable solution code that implements all this here.