OAuth2.0 Tutorial - PART - 5

 

OAuth Flow

1.  Xyz is on the Yelp App, and clicks on a button within the Yelp App which says “Import Contacts from Google”.

2. On clicking on the button, the Yelp App sends the following https request to accounts.google.com.

https://accounts.google.com/o/oauth2/v2/auth?
client_id=yelp1123&
redirect_uri="https://yelp.com/callback"&
scope=contacts&
response_type=code&
state=verifydata

3. Xyz is directed to the accounts.google.com page and prompted to login to accounts.google.com using his google credentials.

4. Based on the “Scope” parameters in the original request, the Authorisation server (i.e. accounts.google.com) constructs a “Consent” page, which describes to the “resource owner” what exactly the “Client” is wanting to access. At this point the “Client” can click Yes/No on the consent page to grant consent to the appropriate resource.

In our example the Consent page will say “Yelp is requesting read access to your google.contacts, do you Consent (y/n)?”

5. Once the “resource owner” clicks on “yes” on the “Consent” page, the Authorisation server returns an “Authorisation Code” to the “Client” and calls the “redirect URI” specified in the initial request.

6. The “Client” now uses the “authorisation code” sent by the “Authorisation server” and using a back-channel communication, exchanges the “authorisation code” for an “access token” from the “Authorisation Server”.

7. Once the “Client” has the “access token” from the “authorisation server” the client can use this “access token” to access google.contacts.

What is back-channel communication?

The back-channel communication is communication sent out by web server to web server, (vs. front-end channel communication, which is communication between a browser and a web server).

Thus, the “authorisation code” is received on the front channel communication i.e. by the browser to web server. But to add that additional layer of security the “authorisation code” is then used by the “Client” web server, and exchanged for an “access-token” from the “authorisation server” by the “client” web server.

OAuth 2.0 Implicit Code Flow

The other commonly used OAuth 2.0 process flow is called the “Implicit Code flow” process flow.

This flow is used when the “Client” does not have a web server (the client may be a pure javascript app, a pure Angular or a pure React App). In this flow the only difference is that the “Authorisation Server” returns the “access token” directly to the “client” (instead of first returning an authorisation code, that must be exchanged for an access token).

A pure javascript app does not have a web server to make the back channel call to exchange the “authorisation code” for an “access token”.

The “OAuth 2.0 Implicit Code flow” is some what less secure, since it does not involve the back-channel exchange, however is the only alternative in case of pure javascript apps (that do not have a web server).

Question: When Should I Use Which?

👍🏾If our requirement involves SSO (when at least one actor or participant is an enterprise), then use SAML.

👍🏾If our requirement involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.

👍🏾If our requirement says to provide access to a partner or customer application to your portal, then use SAML.

👍🏾If our requirement says a centralised identity source, then use SAML  (Identity provider).

👍🏾If our requirement involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.

Question: Is there any possibility when we use SAML and OAuth 

both?

We can use SAML for authentication. Once you have a SAML token/assertion, you can

use that as the OAuth bearer token in the HTTP bearer header to access protected 

resources.

Reference : How to use SAML and OAuth both

https://docs.jboss.org/author/display/PLINK/REST+Service+to+convert+SAML+Tokens+Into+OAuth+Tokens