OAuth2.0 Tutorial - PART - 6

 

OAuth Tokens

Tokens basically are random strings generated by the authorisation server and are issued when the client requests them.

There are 2 types of token being used in OAuth 2.

Access Token: This is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorisation server.

Refresh Token: This token is issued with the access token but it is not sent in each request from the client to the resource server. When access token validity is finished or access token is expired then It could be sent to the authorisation server for renewing the access.

Authentication V/S Authorization

Authentication means verifying that someone is indeed who they claim to be. Authorisation means deciding which resources a certain user should be able to access, and what they should be allowed to do with those resources. Oftentimes, as in our case, an application will require a little bit of both.

Or,

Authentication refers to verifying your identity to an application that you are trying to access. Any application(eg. gmail) recognises who you are based on your username and password. Authorisation refers to what you can access based on your identity.

A Sample example to show implementation of OAuth 2

A Spring Boot Application with OAuth 2 Implementation Link :

http://javatipsbygaurav.blogspot.com/2018/07/spring-boot-security-using-oauth2-with.html

Basically, while implementation of OAuth2, We need to focus on main 4 classes:-

Resource Server  - API

Authorization Server  - API

Resource Owner   - Employee ( As per the given example)

Client  - Application

Authorization Server : This class extends AuthorizationServerConfigurerAdapter and is responsible for generating tokens specific to a client. Suppose, if a user wants to login to deque.com via LinkedIn then LinkedIn auth server will be generating tokens for Deque. In this case, Deque becomes the client which will be requesting for authorisation code on behalf of user from LinkedIn - the authorisation server.

Resource Server : Resource in this context is the REST API which we have exposed for the some operations. To access these resources, client must be authenticated. In real-time scenarios, whenever an user tries to access these resources, the user will be asked to provide his authenticity and once the user is authorized then he will be allowed to access these protected resources.

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