OAuth 2.0 – what you need to know about authorisation types

2019 06 19 · 2 min read

In the last post in this blog, we discussed the facets of the OAuth 2.0 system and how it works. Today, we will devote our post to further examining the possible types of authorisation.

The type of authorisation relates to authorisation of the resource owner used by the application when requesting an access token. The specifications on OAuth2 outline five grant types used for authorisation – authorisation code/authorisation code with PKCE, implicit, client_credentials, password, and refresh token. The way each type is used and applied differs slightly. Three factors should be considered when choosing the type of authorisation: who owns the access token, the type of application, and the type of resource (first-party or third-party).

Authorisation codes

An authorisation code is one of the safest types of authorisation available, yet also the most complex. The purpose of this code is to exchange access token by providing it. It also acts as an intermediary between the authorisation server and the application, allowing the resource owner to be authorised.

This type of operation can be divided into two separate parts:

• Obtaining the authorisation code
• Obtaining an access token by providing the authorisation code

Obtaining an authorisation code

The application redirects the user to the authorisation server, with the following parameters in the query string:

• response_type with a code value.
• client_id with a client identifier. This parameter is obtained after the application is registered with the authorisation server.
• redirect_uri with the client’s redirect URI. The purpose of the redirect function is to take the user to a selected address after authorisation is validated on the server.
• scope with a list of scopes. Through this list, the application obtains information about the user and their access rights.
• state with state parameter. Although this parameter is optional, it is highly recommended and its value should be stored in the user’s session to be validated when they return. The main reason for using a state parameter is to mitigate against CSRF attacks. It comprises a string, so other information can be encoded in it.

Queries, e.g.

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=
https://client.example.com/HTTP/1.1
Host: server.example.com
These parameters will be validated by the authorisation server. The user will also be asked to connect to the authorisation server and confirm permission for the application to obtain the authorisation code. After the user approves this permission, the authorisation server will redirect the user back to the specified redirect_uri with the following parameters in the query string:

• code with the authorisation code. This code can be encrypted with a fixed lifetime and for single use.
• state with state parameter. The authorisation server will return the same value for the state parameter, which should be checked against the one provided in the first step.

Example of a redirected query:

HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

Obtaining an access token by providing an authorisation code

After obtaining an authorisation code, the system proceeds with a POST inquiry to the authorisation server that incorporates the following parameters:

• grant_type with the value of the authorization_code.
• client_id with the client identifier. This parameter is obtained after the application is registered with the authorisation server.
• client_secret with an application login password. This parameter is obtained after the application is registered with the authorisation server.
• redirect_uri with the client redirection address indicated in the request for obtaining an authorisation code.
• code with the authorisation code from the authorisation server.

Queries, e.g.

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri= https://client.example.com/

After the parameters are validated, the authorisation server will respond with a JSON object containing the following properties:

• token_type with value bearer.
• expires_in with a future time expressed in seconds. This represents the time when the token will expire.
• access_token: the access token itself.
• refresh_token: a refresh token that can be used to acquire a new access token when the original one expires.

Security recommendations:

• It is recommended that the authorisation code is encrypted and that its life cycle is as short as possible.
• Allow an authorisation code to be used just once.
• Use an encrypted HTTPS security protocol for communication between the application and the authorisation server.
• Use an encrypted state parameter for CSRF responses.
• Limit the lifetime of access tokens.