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
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.
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.
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.
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.
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.
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:
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.
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.
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.
- Navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/
- press Sign in button
- Login into the open popup
- Accept consent form
- Observe personalized message and token
- Close browser
Single sign on
- Open new browser (InPrivate preferable) and navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/
- Verify page shows you’re not logged in:
- Open new tab and Navigate to www.live.com and login with your Live ID
- Open new tab and navigate to http://www.galcho.com/Blog/content/binary/WLID-OAuth/
- Observe that you’re logged in