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 to reduce planned downtime for OpenEdge applications with Pro2?2023 05 23
Learn more about how Pro2 can reduce downtime for Progress OpenEdge applications.More
Special offer for companies considering cloud migration2023 05 09
Baltic Amadeus, together with Microsoft, offers cloud assessments that help business organisations adopt cloud technologies more easily.More
Discover the magic of ABL: three reasons to love it2023 05 03
Read more about Progress OpenEdge ABL and what benefits it provides in programming.More