Authorization Code Grant Type

What is grant type?

In OAuth 2.0, the term grant type refers to the way an application gets an access token. Each grant type is optimized for a particular use, whether that’s a web app, a native app, a device without the ability to launch a web browser, or server-to-server applications.

In this lesson, we will look at the Authorization Code grant type.

Authorization Code grant type

The Authorization Code grant type is the most commonly used OAuth 2.0 grant type. It is used by both web apps and native apps to get an access token from the authorization server once the user has authorized. The Authorization Code flow is most suitable for websites and mobile apps that have a backend.

This type has the extra step of exchanging the authorization code for the access token. The exchange of authorization code for the access token takes place in the back channel. Due to this feature, it provides an additional layer of security.

Authorization Code grant type Working

Now we will look at the detailed working of the Authorization Code grant type.

Step 1 => Authorization request

In the first step, the client app (PicsArt) redirects the resource owner (the user) to the authorization server’s authorization endpoint. The app sends some query parameters which help the authorization server in identifying the client app and its intent.

The query parameters sent with the request are:

1. response_type: This parameter defines what is the type of response that is expected. In this flow it will be code.

2. client_id: This parameter defines the id of the client that needs access to the resource. In our example, it will be the client id of the PicsArt app.

You might be wondering: where does this client id come from? Every client app first needs to register with an authorization server. When a client gets registered with an authorization server, it is provided a unique client_id and client_secret, which it uses to identify itself to the authorization server.

3. redirect_uri: This is the URI where the authorization server redirect to once it has finished interacting with the resource owner.

4. scope: This parameter defines the resources to which access is being requested. This is not a mandatory parameter, and if it is not provided the authorization server provides access to default resources already defined for this client.

5. state: The application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks.

The complete request looks like this:

https://authorization.server.dummy.com/authorize
?response_type=code
&client_id=12345
&redirect_uri=https://client.dummy.com/callback
&scope=images_read
&state=abcde

The client opens this URL in a browser. The authorization server will present them with a prompt asking if they would like to authorize this application’s request.