User information is vital in a business scenario but could be detrimental if it falls into the wrong hands. To build a secure system, you need to verify whether or not your users are valid and genuine. And we do this through a mechanism called authentication. Authentication uses algorithms and processes to verify if interactions with protected entities occur with genuine external entities.
Typically authentication systems are required in systems that collect and transfer data at a user level. This data may be sensitive, so the systems have to make sure that modification and viewing only happen with valid users or entities. Especially when it comes to sharing and modifying data on third-party applications. Because all the interactions take place on an API level, it’s important to have some measures on the API as well, in order to protect user data.
There are mainly 3 types of authentication
Basic Authentication
API Key Authentication
OAuth 2.0 Authentication
There are other types of authentications as well such as JWT, etc., but this article will solely focus on these three types.
The 3 types of authentication
1. Basic Authentication
In basic authentication, we, as a third-party application, have to include the username and password in the headers or in the body part of the HTTP REST API calls.
The position (path/query param/body/headers) where we place the email/username and password will solely depend on the API configuration.
This is a basic authentication header
Basic authentication header: This is the most straightforward and easy method. With this method, the sender places a username: password into the request header. The username and password are encoded with Base64, which is an encoding technique that converts the username and password into a set of 64 characters to ensure safe transmission.
2. API Key Authentication
API key authentication is used when a particular user is given an API key that’s unique to that particular user account. So whenever the user tries to interact with the system, the particular API needs to contain the same API key that’s specific to that account. That API key would be used to authenticate or verify the user identity in the system before entering the actual system.
API key authentication
In practice API keys show up in all sorts of places:
Authorization Header
Body Data
Custom Header
Query String
3. OAuth 2.0 Authentication
This is the most secure type of authentication out of these three. In OAuth 2.0 authentication, the decision of whether the user is allowed to enter the system or not isn’t as direct as the previous methods. In OAuth 2.0, we have to follow certain flows in order to attain certain string values that the system uses to assess whether the user identity is valid or not.
Access Token
Access tokens are a type of string value that’s used along with the APIs, to prove whether a user identity is valid or not. This token is valid only for a specific period of time e.g. 1 hour. After this period of time, the token will expire, which is where our refresh token comes into play.
Refresh Token
Refresh tokens are string values that are used to generate a new access token when existing tokens expire. So whenever we want to generate a new access token, it will require the third-party application to hit an API in the system that they want to interact with, so that a new access token is granted. Hence using the new access token the user would be validated. In OAuth 2 we mainly have 3 flows:
Granting of OAuth Code
Granting of Access Token and Refresh Token
Refreshing an expired access token
For all the 3 steps that are mentioned above, third-party applications would require to hit 3 separate APIs resp.
Granting of OAuth Code
So the granting of OAuth Code from a system is the first step to gain access and refresh tokens from the system. By using the client ID and client secret, the third-party application will receive a string value that is called OAuth code that would be used for our second step.
Granting of Access Token and Refresh Token
So, the OAuth code that we get in the first step is set as an input for our second API call to the main system. Along with it, third-party applications will also use a client ID and client secret to get the access token and refresh token for their unique identity. So after this step, we, as the third-party application, can use the access token and execute all the APIs exposed from the main system.
Refreshing an expired access token
The refresh token that we got in the second step along with the access token is used as an input to another API. Along with it, we will then use the client ID, the client secret, and other details. After executing it, we will receive a new access token that can be used in order to execute the workflows.