Working with the Live Services are not always an easy task and they are changing and evolving. It’s not always the documentation is updated and it’s not always the infrastructure works the way it’s suppose to. Additionally there are different teams with varied release cycles, which adds to the problems when you’re working with such a major Web 2.0 infrastructure that Windows Live Services really is.
In the recent years, there has evolved various technologies and standards for user identification, authentication and authorization. OpenID is one such mechanism and another one is OAuth which is a relatively new standard on how you can delegate the authentication of the user and do authorization on content that the user owns between different services.
Microsoft’s technology for identification is Windows Live ID and it’s what you use to authenticate with Windows Live Messenger, Hotmail and other services from Microsoft.
There’s only a slight problem with a lot of these mechanisms, they rarely focus and give good support for rich clients that runs on the desktop. OAuth is currently only useable for delegate between different web services.
Microsoft released back in 2007 something called the Windows Live ID Client 1.0 SDK. This is a small API that contains the application logic needed to authorize the user with Windows Live ID and it can be used to generate tokens that is used against the various Windows Live Services that is available.
It was very easy to use this SDK, though the dialog that you get for logging on is not perfect. The Windows Live logo is clearly highly compressed and the controls perhaps not according to the look and feel of your application. Here is a screenshot of the dialog:
Unfortunately, this API doesn’t seam to work together with the latest Live Framework SDK, which is the new and preferable way of communicating with the Live Services. The Windows Live Contacts is the service I’m interested in communicating with, but the infrastructure (“Windows Live Contacts API Beta 1.0”) is being decommissioned in the future.
After some hours of working with the SDK I started to realize it was not going to work the way I needed it too and it did not integrate with the Live Framework SDK, which uses a different form of token, so I had to find an alternative…
After some searching I couldn’t find any better alternatives so I figured it was time to write my own custom dialog for user authentication.
There are different reasons why I was reluctant to make my own dialog, one is security. There are plenty of insecure and poor examples on the web that teaches us developers poor practices when it comes to storing and handling passwords. If I was going to write an example, it had to be something that anyone could copy and use straight away with a minimum layer of security that protects the end users.
Here is the end result of the custom Windows Live ID Logon Dialog:
All the source code is available in the MSDN Code Gallery: http://code.msdn.microsoft.com/WindowsLiveIDLogon
The code includes two project, the primary one is WindowsLiveID which contains the dialog and all the application logic to handle persistence of username and password. If the user chooses to remember their password, it will be stored in the application configuration file in an encrypted form. Encryption is handled by the Data Protection API (DPAPI) which is a framework for encryption built into Windows since Windows 2000. See a quick example on how to use this API from .NET.
Other project is WindowsLiveID.Test and is a standard Windows Forms project that works as an example on how you can enable silent automatic logon in your own application (when the users chooses automatic sign in).
If there are any questions or problems with the above code example, either leave a comment on my blog here or the discussion forum on the code example.