OAUTH2.0 - Implicit Grant Workflow

In this read, we will take a look at OAUTH2.0 and under the implicit grant in the simplest manner (i.e. via a workflow)

What is OAuth2.0

It is an open authorization protocol that allows accessing the resource owner resources by enabling the client applications (like Facebook, GitHub, etc.) on HTTP services. This protocol was made famous by HTTP Basic authentication wherein the user is required to enter the username and password and was created as a response to the direct authentication pattern. It allows the exchange of resources stored on one site with another site by using the credentials token. It used -

To read the user data from another application
Supplies the authorization workflow for web and desktop applications along with mobile devices
It uses the authorization code and does not interact with the user credentials

OAuth2.0 Roles

Resource Owner - It is the person who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted (e.g. read or write access)
Authorization Server - Hosts the protected user accounts, and the authorization server verifies the user identity and then issues the access token to the application
Client - It is the application that wants to access the user’s account

OAuth2.0 Advantages

It is a flexible protocol that relies on SSL to save the user access token
It relies on SSL to ensure cryptography protocol is used to ensure the data integrity
Allows limited access to the user’s data
Allows the ability to share user’s data without releasing the PI information for the users
It is easier to implement and provides stronger authentication

OAuth2.0 Disadvantages

Adding more extensions to the application will require a separate piece of code for each extension

Implicit Grant

This grant is used for mobile and web applications where the confidentiality of the client-secret is not guaranteed
It is a redirection-based flow where the access token is given to the user-agent to forward to the application so it may be exposed to the user and other applications on the user’s device
This flow does not authenticate the identity of the application and relies on the redirect URI
Does not support the refresh tokens
Basically works as follows:
- The user is asked to authorize the application, then the authorization server passes the access token back to the user-agent, which passes it to the application.

Let us understand this via a workflow diagram.