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/