In the Authorization Code Grant Type Flow, we will continue analyze the OAUTH2 example that introduced in OAUTH2 Components
In details, the Authorization Code Grant Type Flow will be happened as the sequence diagram as below.
sequenceDiagram
User->>Client: 1. I want to access my resources
Client->>User: 2. Tell the Auth Server that you are fine to do this action.
User->>Auth Server: 3. Hello Auth Server, please allowed the client to access my resources. <br/> Here is my credentials to prove my identity
Auth Server->>Client: 4. Hey Client, user allowed you to access his <br/> resources. Here is AUTHORIZATION CODE.
Client->>Auth Server: 5. Here is my client credentials, AUTHZ <br/> CODE. Please provide me a token.
Auth Server->>Client: 6. Here is the token from Authorization Server
Client->>Resource Server: 7. Hey Resource Server, I want to access the user resources. <br/> Here is the token from the Authz Server
Resource Server->>Client: 8. Hey Client. Your token is validated successfully. <br/> Here are the resources you requested.
In the step 2 and 3, where client is making a request to the Auth Server endpoint. It has to send below important details.
Names
Descriptions
client_id
The id which identifies the client application by the Auth Server. This will be granted when the client register first time with the Auth Server
redirect_uri
The URI value which the Auth Server needs to redirect post successful authentication. If a default value is provided during the registration then this value is optional
scope
Similar to authorities. Specifies level of access that client is requesting like READ
state
CSRF token value to protect from CSRF acttacks
response_type
With the value 'code' which indicates that we want to follow authorization code grant
In the steo 5 where client after received an authorization code from Auth Server, It will again make a request to Auth Server for a token with the below values.
Names
Descriptions
code
The authorization code received from the above steps
client_id & client_secret
The client credentials which are registered with the Auth Server. Please note that these are not user credentials
grant_type
With the value 'authorization_code' which identifies the kind of grant type is used
redirect_uri
The URI value which the Auth Server needs to redirect post successful authentication. If a default value is provided during the registration then this value is optional
The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token. After the user returns to the client via the redirect URL, the application will get the authorization code from the URL and use it to request an access token.
We may wonder that why in the Authorization Code grant type client is making request 2 times to Auth Server for authorization code and access token.
In the first step, authorization server will make sure that user directly interacted with it along with the credentials. If the details are correct, Auth Server send the authorization code to client.
Once it receives the authorization code, in this step client has to prove it's identity along with the authorization code, client credentials to get the access token.
Well you may ask why can't Auth Server directly club both the steps together and provide the token in a single step. The answer we used to have that grant type as well which is called as implicit grant type. But this grant type is not recommended to use due to it's less secure.
The Implicit Grant Type is less secure that compared to the Authorization Code Grant Type. Let's see the sequence diagram as below.
sequenceDiagram
User->>Client: 1. I want to access my resources
Client->>User: 2. Tell the Auth Server that you are fine to do this action.
User->>Auth Server: 3. Hello Auth Server, please allowed the client to access my resources. <br/> Here is my credentials to prove my identity
Auth Server->>Client: 4. Hey Client, user allowed you to access his <br/> resources. Here is the TOKEN.
Client->>Resource Server: 5. Hey Resource Server, I want to access the user resources. <br/> Here is the token from the Authz Server
Resource Server->>Client: 6. Hey Client. Your token is validated successfully. <br/> Here are the resources you requested.
As you can see in the sequenceDiagram, the Implicit Grant Type has only 6 steps and In the step 4, the Client instead of receiving the Authorization Code, It will receive the Authorization Token and can use it to access the Resource Server.
In the step 3, where client is making a request to Auth Server endpoint, it has to send the below important details.
Names
Descriptions
client_id
The id which identifies the Client application by the Auth Sever. This will be granted when the client register first time with the Auth server.
redirect_uri
The URI value which the Auth Server needs to redirect post successful authentication. If a default value is provided during the registration then this value is optional
scope
Similar to the authorities. Specifies level of access that client is requesting like READ
state
CSRF token value to protect from CSRF attacks
response_type
With the value 'token' which indicates that we want to follow implicit grant type
If the user approves the request, the authorization server will redirect the browser back to the redirect_uri specified by the application, adding a token an state to the fragment part of the URL. For example, the user will be redirect back to a URL such as.
So why do we you it if the Implicit Grant Type Flow is less secure? The answer is some applications just have only UI like they have only HTML and JavaScript codes and they don't have any back-end where they can save the client secret on some back-end servers. So due to that reason, these applications can still use the implicit guarantee. But at the same time, the Auth Server are what they are going to communicate has to allow them to use it, otherwise they can't use it.
Some people call Password Grant Type Flow as the Resource Owner Credentials Grant Type.
In the Password Grant Type Flow, Let's assume that 4 components User, Client, Auth Server and Resource Server are in the same organization and in an internal network of a company. So when the user want to access his resource from the Client application, The Client application doesn't need to redirect the user to the login page of Auth Server, it will capture the user credentials and send them to the Auth Server. Because all components are in the same organization and we can completely believe Client and Auth Server that they won't misuse the user details that they result from the User. Let's see the sequence diagram as below.
sequenceDiagram
User->>Client: 1. I want to access my resources
Client->>Auth Server: 2. Hello Auth Server, User want to access <br/> his/her resources. Here are the credentials of <br/> the User
Auth Server->>Client: 3. Hey Client, The credentials providided are <br/> correct. Here is the TOKEN to access the user <br/> resources.
Client->>Resource Server: 4. Hey Resource Server, I want to access the user resources. <br/> Here is the token from the Authz Server
Resource Server->>Client: 5. Hey Client. Your token is validated successfully. <br/> Here are the resources you requested.
In the step 2, where Client is making a request to Auth Server endpoint have to send below important details.
Names
Descriptions
client_id & client_secret
the credentials of the client to authenticate itself
scope
Similar to the authorities. Specifies level of access that client is requesting like READ
username & password
Credentials provided by the user in the login flow
grant_type
With the value 'authorization_code' which identifies the kind of grant type is used
We use this authentication flow only if the Client, Authorization Server and Resource Server are maintained by the same organization.
This flow will be usually followed by the enterprise applications who want to separate the Auth flow and business flow. Once the Auth flow is separated different applications in the same organization can leverage it.
We can't use the Authorization code grant type since it won't look nice for the user to redirect multiple pages inside your organization for authentication.
In the Client Credentials Grant Type, Let's assume that there are only 3 components Client, Auth Server and Resource Server and we don't have any UI application where there are no User involved. So we just have multiple back-end application which share data between them, like in the micro-service system where many back-end applications trying to interact with each other and shared some secured information between them.
So in this case, instead of maintaining the authentication and authorization flow in each and every application, we can decide to keep all the authorization logic and authentication logic in a separate server called Auth Server and every application before it tries to communicate with other application inside an organization, they have to prove their identity and get the access token from the Auth Server which will be eventually shared to the other application to get the resources. Let's see the sequence diagram as below.
sequenceDiagram
Client->>Auth Server: 1. I want to access protected resources. Here <br/> are my client credentials. No user involved in this.
Auth Server->>Client: 2. Hey Client, The credentials providided are <br/> correct. Here is the TOKEN to access the user <br/> resources.
Client->>Resource Server: 3. Hey Resource Server, I want to access protected resources. <br/> Here is the token from the Authz Server
Resource Server->>Client: 4. Hey Client. Your token is validated successfully. <br/> Here are the resources you requested.
In the step 1, where client is making a request to Auth Server endpoint have to send the below important details.
Names
Descriptions
client_id & client_secret
the credentials of the client to authenticate itself
scope
Similar to the authorities. Specifies level of access that client is requesting like READ
grant_type
With the value 'authorization_code' which identifies the kind of grant type is used
This is the most simplest grant type flow in OAUTH2.
We use this authentication flow only if there is no user and UI involved. Like 2 different applications want to share data between them using backend APIs.
In the Refresh Token Grant Type, Let's assume that we are using one of 4 Grant Type Flow Authorization Code Grant Type, Implicit Grant Type Flow, Resource Owner Credentials Grant Type and Client Credentials Grant Type and we got the access token from the Auth Server and sent that to the Resource Server and got the required resources. However, for example after 60 minutes, suddenly the token is expired so now we have to do steps for getting authorization token again and after 60 minutes we again have to do it. Due to that reason, we should apply the Refresh Token Grant Type, in details whenever we interact with the Auth Server and receive the access token, we also receive the refresh token. Then whenever we get the error from the Auth Server saying that our access token is expired so instead of doing steps for getting authorization token again we will send the refresh token to the Auth Server to get the new access token. The Auth Server will validate the refresh token that it issued and if the refresh token is valid and if it belongs to the same user that it initially issued the the Auth Server will issue again a new access token with the new expiration time along with the new refresh token. Let's see the sequence diagram as below.
sequenceDiagram
Client->>Resource Server: 1. I want to access protected resources of the user. Here <br/> is the access token received in the initial user login.
Resource Server->>Client: 2. The access token is expired! I'm throwing 403 <br/> forbiddent error. Sorry!
Client->>Auth Server: 3. Hey Auth Server, I need a new access token <br/> for the user. Here is the refresh token <br/> of the user.
Auth Server->>Client: 4. Refresh token is valid. Here is a new access <br/> token and new refresh token.
Client->>Resource Server: 5. Hey Resource Server, I want to access protected resources. <br/> Here is the token from the Authz Server
Resource Server->>Client: 6. Hey Client. Your token is validated successfully. <br/> Here are the resources you requested.
In step 3, where client is making a request to Auth Server endpoint have to send the below important details.
Names
Descriptions
client_id & client_secret
the credentials of the client to authenticate itself
refresh_token
the value of the refresh token received initially
scope
Similar to the authorities. Specifies level of access that client is requesting like READ
grant_type
With the value 'authorization_code' which identifies the kind of grant type is used
This flow will be used in the scenarios where the access token of the user is expired. Instead of asking the user to login again and again, we can use the refresh token which originally providied by the Auth Server to re-authenticate the user.
Though we can make our access tokens to never expire but it is not recommended considering scenarios where the tokens can be stole if we always use the same token.
Even in the resource owner credentials grant types we should not store the user credentials for re-authentication purpose instead we should reply on the refresh tokens.
