OAuth 2.0 – what you need to know about authorisation types2019 06 19
Author: Evaldas Jurgaitis
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).
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.
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.
POST /token HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
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.
- 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.
How can you reduce electricity costs by using public cloud solutions?2023 01 16
Explore three main reasons how public cloud solutions help to reduce energy costs.More
What is cloud computing security?2023 01 12
Learn how to ensure security in the cloud by following a few simple steps.More
How do cloud services help to handle a seasonal peak?2022 11 07
Learn how the public cloud helps manage and optimise trading systems during the seasonal peak.More