Messenger Connect::: In Part One, we looked at the basic capabilities and the setup of security information between services. In Part Two we looked in detail at the OAuth WRAP Protocol. In this part we look at how the informaiton is retrieved from the WIndows Live API Service.
We left it in part two wihere the web browser has the equivalent of access and refresh tokens. The next job is to use them to retrieve the Windows Live information (profile, contact, calendar, activities etc) from the Windows Live API Service.
These 2 terms are often mixed up and used interchangeably, but they are different and quite distinct from each other. A few years ago, the actor Brad Pitt suffered an embarrassing moment at one of theee red-carpet awards ceremonies. His car pulled up at the red-carpet, the official duly opened the door and out he swooshed looking very dapper in his black-tie, shiny shoes and cummerbund. Thhheee crowd cheered, the photographers snapped and all that could be heard just above the screams of the admiring women was "Brad, look this way", "Hi Brad", "Brad, over here", "This way Brad". That was when the security guard stood in front of him and uttered those immortal words "you're not on the list". I've no idea what he said, the crowd were screaming "but it's Brad Pitt". The security guard knew exactly who it was - he just wasn't on the list.
It's an example of the difference between authentication and authorization. Authentication is proving that you are who you say you are. In that case, the only thing Brad had to do was turn up looking exactly like Brad Pitt. There were a few thousand people there all authenticating him. Authorization is what you are permitted to do once you have been authenticated. In this case, Brad was refused entry to the building because he wasn't on the list. The authentication worked perfectly. The authorization worked perfectly too. He got "access denied". Until eventually it was sorted out because of an error.
In the case of the protocol exchanges you saw above, the authorization process had an implicit authentication process built-in. Understand though, this was used purely as a bootstrap in to the authorization process. Until Windows Live knew who you were, it couldn't work out what you were allowed to do. Essentially this authorization process allows you to give consent for a web site to get access to your Windows Live information (profile, calendar, contacts, pictures etc). In this way, it's really a consent process.
Typically the thing the client application (remember, this is the site you will build J) will do next is retrieve the information you agreed to release at the consent stage (step 5 and figure 5 in the description in part two). We don't need to know how this is codified in to the token. The token is opaque, there is an agreed way of encrypting and signing the token between the Windows Live ID Access Token URL and the Windows Live API Services. Even if we put a low level network monitor on the exchange, all we'd see is an encrypted token. So we simply live with the fact that Windows Live ID and Windows Live API Services have some form of agreement between themselves concerning how an authorization is to be codified.
There might be various controls, buttons, check-boxes and things to click on your site. Anytime your site needs to get information from the Windows Live API Service it will need to do the following.
This is the point at which we need to discuss the client scope mentioned earlier. And this gets in to the tetchy area of privacy. But I'll save it for the next instalment.