Users have a secure way to access internet services without having to worry about their login credentials thanks to the OAuth authentication framework. The most recent version of an open standard, OAuth 2.0, was developed to enable generic apps to access internet services using your identity without needing to know your username and password for those services.

• We have a variety of ways to receive the Access Token from the Authorization Server using Client Applications thanks to Oauth 2.0 Grant Types.
• In OAuth 2.0, each grant type is tailored to a specific use case, whether for a web application, a native or React application, or a device that cannot run a web browser or server-to-server apps.

Most Java development companies are well-versed in these grant types. In this blog, we will understand each of the Grant Types in Oauth 2.0.

What are the Grant Types in Oauth 2.0

1. Implicit Grant Type

• In Oauth 2.0, this is the most basic grant type.
• Access tokens that are not kept on secure servers can be obtained via the authentication server using the implicit grant type.
• In this grant type, the access token is sent directly from the authorization server to the Client application. Although it does not need a web server, it is less secure because the access token must be kept on the user or client’s device.

Working flow: 

1. The user gives their credentials to the Client application because they wish to access their account.
2. The client application transmits these credentials to the authorization server.
3. These credentials are obtained by the Authorization Server, which then checks them against the database. The access token will be generated and given to the client application if it is legitimate.
4. The authorization server receives client credentials and access tokens from the client application.
5. Then, the authorization server is contacted by the Resource Server to verify the access token. When a request is legitimate, the resource server creates a response and sends it to the client application, allowing the user to quickly access the requested data or information. 

2. Authorization Server Code  

• The authorization code grant type initially looks quite complicated, but it’s simpler than you think once you’re familiar with a few basics.
• Web and mobile applications both use the Authorization Code grant type. It is different from the other grant types.
• In this flow User or Resource, the owner gets the authorization code first from the authorization server and the user sends that authorization code to the authorization server in exchange for the access token.
• The Authorization Code flow is mostly used by Single Page Applications (SPA) and mobile/native applications.
• In this flow, the token is stored on the server side so it is more secure than the implicit grant type. 

Working Flow

1. First Users access the client application.
2. Client Application sends the authentication request to the resource owner.
3. User/Resource Owner provides their credentials and requests a pass to the authorization server.
4. The Authorization Server gets those credentials and verifies them with the database if it is valid then it will generate the authentication code and pass it to the client application.
5. Client Application sends the authorization code to the authorization server to get exchange of the access token.
6. The authorization server gets that authorization code if it is valid then it will generate the access token and pass it to the client application.
7. Client Application sends the access token to the resource server to get the data from the server.
8. Resource Server Validate the token with the authorization server if it is valid then the resource servers generate the response and send it to the client application so the user can easily get the data or information from the client application.

3.  PKCE Grant Type with Authorization Code Flow

• This grant type is similar to the authorization code but it has additional steps that make it more secure for mobile and native applications or single-page applications.
• It helps protect you against various code injection attacks.
• This grant type has mainly two parameters

1. code verifier: It is nothing but a random string between 43-128 characters. it is stored in our local system.
2. code challenge: It takes the code verifier as input and does hashing with different hashing techniques and generates the base 64 URL encode.

Working Flow

1. The user clicks on the login link.
2. Generate the code verifier and store them in the local machine.
3. Client Application sends the authorization code request along with the code challenge to the authorization server. This code chall,enge gets stored in the authorization server.
4. The authorization Server redirects the user to the login page.
5. Resource owner enters their credentials and passes them to the authorization server.
6. Then the authorization Server gets those credentials and verifies them with the database if it is valid or not. Then it generates the authentication code and passes it to the client application.
7. Client Application sends the auth code and the code verifier to the authentication server.
8. The authentication server validates the code verifier and code challenge if it is valid.
9. Then, It will generate the access token and id token and pass them to the client application.
10. Client Application Send the access token to get the data from the resource server.
11. The resource server gets the access token and validates it to the authorization server to check its validation. Then it the response and pass it to the client application so the user /resource owner can get the data or information easily.

4.  Device Flow

• It is a grant type that is primarily used to receive an access token on devices with restricted browser input capabilities, such as mobile phones. applications for TV. 

Working flow

1. User starts the device application(TV application)
2. Device sends the authorization request to the authorization server (with the device code)
3. Authorization server will return the three parameters (device code + user code + verification  URL)
4. User code + verification URL will be sent to the user or resource owner.
5. Device app continuously polls the token from the authorization server.
6. Authorization server will check the credentials and verify if the user is authorized or not.

• 1. In the verification URL enter the user code
• 2. Page will be redirected to login/authorization prompt
• 3. Authenticate and consent
• 4. Device will be marked as Authorized.

7. If the user is authorized then the authorization server will generate the access token and sends it to the device application.
8. Device app will request the resource server to access the API with the generated Access token.
9. Resource server will send the response back to the device application.

Analyze client requirements 

Working  Flow For The Different Grant Types  

• When a client application (such as Github, Google, etc.) is acting on behalf of the resource owner or user, we first look to see if the resource owner uses a web browser while using the client application. If this is the case, we then look to see if the client application is entirely contained within the web browser and if so, we use the implicit grant type for authorization.
• Choose the authorization code grant type if the client application is not fully supported by a web browser, and the PKCE grant type if the client application is native.
• The user will utilize his or her credentials for authorization if the user or resource owner is not engaging with the web server.
• The user or resource owner uses their credentials for permission if the client application acts on their behalf.
• Whether the client application isn’t operating on the client’s behalf, we’ll check to see if it’s acting with permission from a third party, and if the answer is yes, we’ll opt for the assertion flow for authorization.

These are the Oauth 2.0 grant types. You can speak with our experienced Java developers to obtain more clarification.