Javadoubts

OAuth2.0 Authorization

This tutorial will provide deep knowledge on OAuth2.0 and will help us to understand the concepts and major terminologies around OAuth2.0.

OAutho2.0 stands for Open Authorization. OAuth2.0 is a protocol which allow client application to have a required secure access of resource server with the help of access token and without sharing username/password.

There are three main components we need to keep in mind when we try to make a connection in between client application and server:

Client: Client is an application server which access required details from resource server.

Authorization Server: Authorization sever provides us the access token with the helps of client ID and client secret which helps us to get required access.

Resource Server: Resource server helps us to provide required data depending on valid access token.

Note: In case of Authorization, only authorized access will allow us to access resource server.

Why we need AOuth2.0 ?

Let’s try to understand some more authorization techniques before we actually dig into OAuth2.0.

No Authorization

Accessing an API without having any kind of authorization, whether by a valid or malicious client, will always allow us to access the resource server through the API and fetch the data. In this case, the resource server does not validate the client and returns the required result. This is also called as No Authorization.

Basic Authorization

Passing an username and password to make above No Authorization API call more secure called as Basic Authorization.

Basic Authorization is insecure as it has its own below drawbacks:

• Sending password over network is not safe.
• username/password gets cache/save by the browser.
• Lastly every API call require to send username/password to fetch data.

How OAuth2.0 actually works and solves above issues

OAuth 2.0 allows us to access the resource server with the help of an access token. The access token is generated through the authorization server using the client ID and client Secret.

In OAuth2.0, we don’t provide username and password to make an API call.

Let’s discuss every step-in detail as client application try to access authorized resource server with the help of access token mentioned as part of above flow diagram:

Step1: With the help of client id and client secret we can make a server specific call to get an access token.

Step2: This step will provide an access token and refresh token in return on passing valid client id and secret.

Step3: Pass the access token to the resource server to fetch the required data.

Step4: Return required requested data on passing valid access token.

Note: An access token can be regenerated once it has expired with the help of a refresh token, as the refresh token typically has a longer expiration time compared to the access token.

OAuth2.0 Success and Fail Scenario

Below is the overall API flow for fetching data from the resource server, utilizing client ID, client secret, access token, and refresh token.

Planning to make API calls from front end to access resource server to fetch data ???

Follow below steps to make secure calls to resource server from the front end:

1. Save environment specific client ID and client secret on the client application backend server.
2. Make POST call from backend to required server for generating an access and refresh token.
3. Save the refresh token on the client application server in the backend, as part of cookie or session. The refresh token must not be visible in public or to the end users.
4. Make a call from the front-end client application to the backend client application server to fetch an access token.
5. Make calls to the resource server to retrieve the required data using the access token obtained as part of earlier fourth step.
6. In case the earlier access token expires, make a call from the front-end client application to the backend client application server to obtain a new access token.

Very Important API Securing Notes:

Access token must always be short live and use refresh token to generate access token as refresh token used to have more expiry time. Refresh token should never be publicized as it may be a big threat to a server. Always try to keep it safe and save it somewhere on server.

Try to use encrypted client ID and client secret to hide its original identity. client ID and client secret should never be used in the public through the front end or made available in the network tab.

Enforce the client ID as part of security and enable the CORS policy within the authorization/resource server. This will ensure that the authorization/resource server only accepts data manipulation (create, update, delete, etc.) calls from specific whitelisted domains/servers. There will not be a significant issue if someone obtains this access token due to its short lifespan and the presence of CORS.