In part one I gave an overview of what was possible and started down the journey of the verious bits of setup that had to be done, eith erby you, or setup that has already been done by the WIndows Live team. In this article I show how the OAuthWRAP protocol works with Messenger Connect.
Windows Live ID is the Authorization Server. It implicitly trusts the Live IDs in its database because it created and issued them. But when it gets down to your site, it needs to have some assurances that the site that comes to it purporting to be your site is in fact your site. To this end it will create and share a couple of secrets with you. In OAuth WRAP terms, your site is known as the client application, hence the secrets are termed the client ID and the client secret. It's important that you keep these secrets, well, secret.
To obtain these secrets you must go through a registration process with Windows Live ID (the Authorization Server). You'll be asked for the site's domain name and the URL of a callback handler (covered later). The secrets will be stored against the domain and URL. Whenever your site communicates with Windows Live ID, all the parameters must match up; the URL, the domain, the client ID and the client secret. Security and authorization error messages invariably end up with one or more of these parameters not matching up correctly.
While the product is in Beta, you can't register a domain unless you have also applied to join the Beta and been accepted on to the program. You are informed by email of your successful registration. This process can take a few days, so make sure you allow for it in your schedule. You'll be asked questions about the number of users that hit your site and the scenarios you want to try. As a general rule, if you fill in all the fields accurately, the scenario you want to deploy is supported and the site is a genuine site, you will be accepted on to the Beta program. You'll need a Live ID to register.
To register, go to http://dev.live.com and click the "Join the Beta" button.
Once you are registered, you can add additional URLs and manage their secrets. You can also upload logos that will be used in authentication challenges and so on. This is done at http://manage.dev.live.com.
Figure 2: Client application management at http://manage.dev.live.com
Once all this basic setup (certificates, client ID, secret, callback URL, domain name) has been completed, you can create/modify the pages in your site with the aid of the Windows Live SDK.
First, a protocol diagram:
Figure 3: OAuthWRAP protocol exchanges in Messenger Connect
Each element is numbered 1 - 17. At the end of this, the browser will have cookies that represent security tokens. Your web site will take these cookies, convert them to tokens and use them to access, for example, Windows Live profile information, or contact information.
Figure 4: Windows Live Consent Page
...clicking the "what will I share" link, shows something similar to the following:
Figure 5: What you will share
In Part 3, we'll have a look at how the tokens are passed to the Windows Live API Service and the data retrieved. Then in subsequent parts we'll look at some code and show how the various pages and services link together. I'll cross reference the code that runs with the protocol diagram so you should be able to work out what's going on.