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.
Skaistė Krikščiūnaitė to become Baltic Amadeus Head of Marketing2021 06 10
Skaistė Krikščiūnaitė has been appointed the new Head of Marketing at the IT company Baltic Amadeus. Ms Krikščiūnaitė joined the strategic change team of the company, which is currently growing and looking for new personnel, in late June.More
Baltic Amadeus in a Collab with Talend: Helping Organisations Manage Data Chaos2021 06 03
The developer of unique IT solutions, Baltic Amadeus has signed an agreement with the company Talend (NASDAQ: TLND) that provides data management products. The solutions of this world-leading company allow organisations to manage data chaos by ensuring that the data stores across different systems are mutually compatible and fully correct. Talend also helps with the dilemma of processing data in strict legal compliance while at the same time providing their employees with the necessary access to that data.More
Baltic Amadeus Plans an Expansion with New Digital Products2021 05 11
The developer of unique solutions, Baltic Amadeus, reported an income of nearly EUR 11 million in 2020; despite the pandemic, its sales remained stable. To continue its successful export operations, the company in planning to expand in the pan-Baltic region and invest in the development of new digital solutions.More