Sunday, 27 September 2015

OAuth 2.0 - Single sign-on (SSO)


1.- A user opens their web-browser and goes to travelocity.com which stores all of their info.
2.- travelocity.com doesn't handle authentication itself, so the user is redirected to the Identity Provider with a request for authorization. The client receives an authorization grant code as a part of the redirect and then passes this along to the client.
3.- The Client then uses that authorization grant code to request an access token from the Identity Provider.
4.- The user is presented with a login form and is asked if they want to approve the Resource Server (travelocity.com) to act on their behalf.
5.- The user logs in and if the authorization grant code is valid, then the Authorization Server grants an access token. The client is redirected back to travelocity.com.
6.- The access token is then used by the client to request resources from the Resource Server (travelocity.com).
7.- travelocity.com receives the request for a resource and it receives the access token. In order to make sure it's a valid access token it sends the token directly to the Identity Provider to validate. If valid, the Identity Provider sends back information about the user.
8.- Having validated the user's request travelocity.com sends the requested resource back to the user.

https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/

Saturday, 12 September 2015

SAML 2.0 - Single sign-on (SSO)


Security Assertion Markup Language 2.0 



1.- A user opens their web-browser and goes to travelocity.com which stores all of their info. travelocity.com doesn't handle authentication itself.
2.- To authenticate the user travelocity.com constructs a SAML Authnrequest, signs it (public certification), optionally encrypts it, and encodes it. After which, it redirects the user's web browser to the Identidy Provider (IdP) in order to authenticate. The IdP receives the request, decodes it, decrypts it if necessary, and verifies the signature (public certification of travelocity.com).
3.-Login Page. With a valid Authnrequest the IdP will present the user with a login form in which they can enter their username and password.
4.- Once the user has logged in, the IdP generates a SAML token that includes identity information about the user (such as their username, email, etc). The Id takes the SAML token and redirects the user back to the Service Provider (travelocity.com).
5.- Access Control Decision: travelocity.com verifies the SAML token, decrypts it if necessary, and extracts out identity information about the user, such as who they are and what their permissions might be. travelocity.com now logs the user into its system, presumably with some kind of cookie and session.
6.-At the end of the process the user can interact with travelocity.com as a logged in user. The user's credentials never passed through travelocity.com, only through the Identity Provider.

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language