It's not about what we have, it's about what we share... Part Three

  • Article

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.

Authentication vs. Authorization

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.

Getting hold of your Windows Live information

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.

  • Retrieve the cookies that contain the data used to create the access token and expiry information.
  • Check the expiry information. If the access token has expired, a new one will be required. The refresh token can be used to request a fresh access token. The expiry information for the refresh token also needs to be checked. If the refresh token has expired, the entire process will need to be started from scratch. This is a safety measure. We'll talk about refreshing tokens later. Let's assume the access token is valid.
  • Use the data in the cookie to create the access token. Remember the access token is opaque (it's encrypted). That's why we can't just simply crack it open and check the expiry information within the token.
  • Make a call to the necessary information (in this case, from step 5 and figure 5 above it is view:Live Contact Information and view:Windows Live Profile information) at the Windows Live API Service with the access token embedded in to the HTTP header.
  • The Windows Live API Service will first validate the signature and decrypt the token (I described that in Part One), then check that the authorizations in the token meet the desires of the owner. For example in the intervening period, the owner might have put a more restrictive permission on the data. Let's assume this is successful.
  • The Windows Live API Service will return the requested data.

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.

Planky