Galin Iliev's blog

Software Architecture & Development

Single sign on with Windows Live Id and OAuth 2.0

9. October 2011 Galcho OAuth (0)

Introduction

At some point part of developing a website was creating its own AuthN system with credentials valid only for the website being built. Having lot’s of people doing this it created trouble for users remembering all the credential, emails, passwords, secret questions and so. Not to mention security implications.

Luckily at some point the biggest players started sharing the logins and OAuth was born. OAuth 1.0 was a bit complicated and this is why an effort to OAuth WRAP and OAuth 2.0 (still work in progress) is here. Having major players almost all user has accounts in one or more on the following services:

All of the above are using OAuth 2.0 which requires SSL and is the easiest version to use

Signing flow

It is described very well in OAuth 2.0 spec and in OAuth 2.0 implementation on WLID. I will put the steps here for completeness.

  1. The client initiates the flow by directing the resource owner's user agent to the Live Connect authorization endpoint, by using a URL in the following format. 

    https://oauth.live.com/authorize?client_id=CLIENT_ID&
	scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URL

    This URL contains the client ID, requested scope(s), local state, and a redirection URI to which the authorization web service is to send the user agent after access is granted or denied.

  2. The authorization server authenticates the resource owner via the user-agent, and establishes whether the resource owner grants or denies the client's access request.

  3. Assuming that the user has granted access, the Live Connect authorization server redirects the user agent back to the client by using the redirection URI that was provided in the initial request.

  4. The user agent calls the client with the redirection URI, which includes an authorization code and any local state that was provided by the client. For example: http://contoso.com/Callback.htm?code=[authorizationcode].

  5. The client requests an access token from the authorization server's token endpoint by using its client credentials for authentication, and includes the authorization code that was received in the previous step. The client includes the redirection URI that was used to obtain the authorization code for verification. The request URL has the following format: https://oauth.live.com/token?client_id=CLIENT_ID& redirect_uri=REDIRECT_URL& client_secret=CLIENT_SECRET& code=AUTHORIZATION_CODE& grant_type=authorization_code.

  6. The Live Connect authorization server validates the client credentials and the authorization code, and ensures that the redirection URI that was received matches the URI that was used to redirect the client in step 3.

  7. If the credentials are valid, the authorization server responds by returning an access token.

Single sign on example

Since It is based on so called 3rd party application first login is needed to accept consent form.

Preparation steps:

  1. Navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/
  2. press Sign in button
  3. Login into the open popup
  4. Accept consent form
  5. Observe personalized message and token 
    image
  6. Close browser

Single sign on

  1. Open new browser (InPrivate preferable) and navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/ 
  2. Verify page shows you’re not logged in:
    image
  3. Open new tab and Navigate to www.live.com and login with your Live ID
  4. Open new tab and navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/ 
  5. Observe that you’re logged in

 image

 

Resources: