1. Introduction

Nowadays most of the developers are facing some issues when selecting a grant type for their authorization,authentication purposes of their applications. So this article may brief some knowledge about how to select a proper grant type for an application. Simply grant is a process where the users/clients can acquire the access token to access a resource. I’ll try my best to explain these things in a simple and understanding manner in my words of preference.

Let’s move to the topic ” Which Grant Type Should Use According to Your Application “, So this is based on the application that you are building. Basically applications can grouped under four categories, 

Those are as ; Native , Single Page , Server Pages and Background.

As you all know the Native apps are the applications that run on the desktop, phone (android , ios , WPF applications), Windows forms or swing applications. Single page applications are the applications where we can download them via a server and run directly on the browser, these types of applications mostly based on java-script (Angular,React Frameworks,etc). Server page applications are the ones mostly like JSP servlets, Python, PHP and finally Background applications which run on the server side users haven’t any interaction with these applications.

So the developers have used many techniques to protect the privacy and secure them. If we take a look at the past few years before like 2010, most of the applications, servers got hacked and faced on Cyber attacks. As a result , many organizations faced much trouble. The main reason for this is because these days the technology is not much developed to secure sensitive data, so on behalf of simple authentication methods the Grant types were introduced.

As above mentioned, according to the application types and according to the context of usage, developers can used the grant types to secure their applications, below are the grant types which I’m going to discuss all over this article;

• Client Credentials
• Password
• Authorization Code
• Implicit
• Authorization Code PKCE

1.1 Client Credentials

The above session has a brief introduction about the background applications, so if it is a background application for sure we should use the client credentials grant type. So furthermore explanation here’s how this grant type works. Just imagine there’s an application, that application has a client secret and it passes the id and secret to the server (Identity server), in return server response with an access token. After gaining the access token the application calls the API server with this access token to request data via a resource.

According to the explanation it’s easy to understand the process, simply in the request it passes the client ID and the Client Secret, in return of the response we can have an access token. Basically this grant type is used on B2B scenarios, no user interactions background applications take place.

Figure 1.0

1.2 Password

When an application has end users and if the application is highly trusted by the user the Password grant mechanism is used. So now we’ll see how the password grant works. Let’s imagine there’s an application and the end user gives his user name and the password to that application. After that application takes that given username and the password by the user with addition of its own client ID and the client secret and sends a request to the identity server so as in the above scenario it returns the response with the access token and then after application use the access token to communicate with API server. So in this case both are authenticated the server application and the user but in this case the application must be highly trusted because the password and the user name is given by the user.

In addition to the above process here there’s adding the username and the password with client ID and client secret in the request, in returns of response we can have the access token.

Figure 1.1

1.3 Authorization Code

This grant type is used when the user is not providing the password directly to a specific application, the difference between password grant and the Authorization code grant is that. So we’ll discuss this grant type as well as the above , so here the user gives his password directly to the identity server and the application gives its client secret to the identity server. In this case both are authenticated directly via the identity server.

Now will go through the entire flow; when user made a request to the application it’s redirect to the identity server the identity server authenticated the user , once it authenticated the authentication code is issued from the identity server and redirect back to the application with the authorization code, then after application sends a request to the identity server with the authorization code, client ID and the client secret if the all information send was valid the access token will be generated as the response from the identity server, In this stage both the user and the application are authenticated. And finally the application can access a resource in the API server with the generated access token.

So when summarized the above scenario firstly user makes a request on the application with his/her username and password to the application, then it redirect to the identity server and generate an authorization code, so keep in mind at this stage the user is fully authenticated and in next step application makes the request to the application with authentication code,client ID and client secret at that moment identity server response with the access token now the both application and user is authenticated.

Figure 1.2

For your knowledge

There are two ways of authentication: one is called 2 legged approach and the other is 3 legged approach. In a 2 legged approach the user speaks to the application directly and never speaks to the identity server directly. And in a 3 legged approach the user directly speaks to the identity server and gets authenticated and then passes the access token to the application for access.

1.4 Implicit

Now let’s go through the implicit grant type. This is mostly similar to authorization code with additional few steps. In this scenario as in the authorization code the user makes a request to the application it’ll redirects to the identity server from the identity server it will generates a access token, so here’s the point you can remember in the above scenario the identity server generates an authorization code but in this scenario the identity server generates an access token directly so by the way you can access the API server directly via using generated access token.

So let’s talk about the missing part here regarding authorization code and why do so. In the authorization code there used client id, client secret and authorization code to authenticate the application but in implicit it’s not processed. The reason is the application is browser based (edge) or native, so for these purposes we cannot manage client secrets as a result of implicit grant we cannot process with an authorization code.

Developers must be careful when using this Implicit grant because only the user has been authenticated. So there’s a possibility to hack the system or malicious applications may miss use it.

So as in the above scenarios firstly user makes a request on the application with his/her username and password to the application, then it redirect to the identity server and generate an access token, so you guys keep the point mind here the identity server directly generates the access token not the authorization code, so then after it can directly access the API server with the use of this access token.

Figure 1.3

1.5 Authorization Code PKCE

When talking about Authorization Code PKCE it’s a modified version of Authorization Code, Let’s have a look on why it’s modified; so when the application is a single page application or native application it’s better to use Authorization Code PKCE, in this grant type there’s no necessity to have client secret, here’s a point to keep in the mind in Authorization code grant there needed client secret for authorization but in Authorization Code PKCE it’s no need of having a client secret it’s manage it itself and validate the application, so that’s an advantage of this grant.

So when we go deep in this grant, single page applications also when there’s no browser support on web crypto it falls to use implicit other than that we can move forward with Authorization Code PKCE.

Now we’ll see how this Authorization Code PKCE grant flows. It’s similar to Authorization code and only different here; it does not move forward with client secret, but additionally few steps are here.

When a user makes a request to the application, the application generates a code verifier, hashes the code verifier which we called it as a code challenge and then sends the code challenge to the browser, and browser forwards that request to the identity server then the user authenticates. Once the user gets authenticated code challenge is stored in the identity server with the auth code. Then the auth code forwards to the browser and through the browser the auth code is forwarded to the application. So at this moment the user is totally authenticated.

Let’s see how the application is got authenticated now ; The application sends the code verifier to the identity server along with the auth code and then in the server side it’s compared with the stored code challenge with there request makes from the application so if the both are compatible from the identity server side it returns the access token with response. So finally the application is able to access the API server with the generated access token.

In addition to your knowledge the code verifier removes the necessity of having a client secret on authorization purpose.

Figure 1.4

2. WSO2 Identity Server

This is an open source Identity and Access Management solution which facilitates single sign on between applications. As I experienced this was an amazing product to manage the applications with grant types. 

In the Identity server console you can easily create your application and select the grants according to your preference.

Below are some snaps of the WSO2 Identity server console. (used the latest version of WSO2 Identity server – 6.0 ) so as in the below attachment when you logged to the WSO2 Identity server console you can configure your application,

Figure 2.0

Figure 2.1

After creating the application by providing required information, there’s a section called protocol; so here the user can select the grant types. In the very beginning there’s a brief clarification on according to your application type which grants will perform well.

So just have a look on below attachment;

Figure 2.2

According to the selected application type you will display relevant grant types. And also In the same section you can configure Authorization Code PKCE also,

Figure 2.3

So according to the above clarification, WSO2 Identity Server is a recommended option to manage applications with grants. It’s much more secure and easy to manage.

3. Summary

There are four types of applications: Native , Single Page , Server Pages and Background.

For Native application you can use Authorization code PKCE, Single page you can use Authorization Code PKCE but if it’s not supports browsers implicit (have security risk), Server pages it’s better to use password grant in the occasions user is willing to give username and password to the application and in other half Authorization code is better and finally in background applications user haven’t interaction with and only interacts with the server so it’s better to move forward with client credentials grant.

4. Conclusion

This is a rough idea of how the grants work and according to your application which grant is to be used.  So according to my point of view, for better understanding the practice is the most valuable thing to have rock solid knowledge on any subject matter. So before you implement it’s better to read this article top to bottom, I hope it will be a great assist on your work stuff.