When working with APIs, you may have to work a lot with user authentication. It may vary according to different usage. The article will learn about common ways to perform authentication when doing with api.

1. Authentication and authorization

Before learning about the methods, we will briefly understand the difference between authentication and authorization
Authentication : is defined as when the entity proves what identity is or simply answers the “who you are” question.
Authorization : defined as an entity that proves to have access, as simple as having a key but only allowed to open a few doors in the house, not all the doors. In other words, it answers the “what you can do” question.

2. Common methods using authentication

2.1 Basic Authentication

This authentication method is less recommended because its security is not secure. In this method, it is very easy to do the following. The sender will send your username and password in the request’s header. The username and password must be encrypted as Base64 to ensure more security.
This method may not require cookies, session IDs, etc. because it only needs to be used with the http header, without the need for support from another response. An example of the request header uses this method

Find out more about this method and how to do it here

2.2 Bearer Authentication

This method, also known as token authentication, can be simply understood as “granting bearer access to this token”. The bearer token will allow access to certain resources or urls and usually an encrypted string generated by the server in the response to make the login request.
When done by this method, the client must send this bearer token in the header to make the request

How to do it with bearer authentication can be as follows:
When the user sends requesst to the server to get a token with username and password via SSL, the server will return an access token string. This access token is the bearer token that the client needs to send into the header if it wants to make other requests to the server to authenticate that user. This token can be an encrypted string with the user’s attributes, the role of that user. When the server receives this token, it will decode and then execute that validate request in the application to see if the user is authorized to make that request. This token will usually be limited (for example, 30 minutes after it will expire) because it is possible that the user’s role will change during execution. There will be instances where the user with role = “Admin” changes to “User”. If the token does not expire, the old token with role = “Admin” will still have access to that role, even if it has been changed.

2.3 Api Keys

This method was created with the purpose of fixing the problems of basic authentication. In this method, a unique key value is generated and assigned to the user for the first time, indicating that the user is identified. When the user returns to the system, the unique key (which may be generated from a combination of hardware information, IP address and server time) is used to prove that the user is the same for the first time.

Many API keys are sent as part of a query string to help identify who should not have access. A better option is to send the api key in the authorization header, like the type of Authorization: Apikey 1234567890abcdef .

In fact, the api key appears as:
. Authorization Header
. Basic Authen
. Body Data
. Query String
In some cases, it is possible to use api keys, for example, where an api is restricted with read-only permissions. In case of use with authentication rest api, you need to pay more attention to security issues.

2.4 OAuth (2.0)

OAuth stands for Open with Authentication or Authorization. OAuth was born to solve these problems and beyond, this is a way to authenticate applications that can share resources with each other without sharing username and password information. OAuth includes four different roles:
Resource Server : REST API is an example, an HTTP server where users can create, modify or delete records, documents or files.

Resource Owner : Maintain ownership of resources that users have created or modified on the server and authorized third party applications to access their accounts. 3rd party applications have limited access to user accounts, based on the scope of the scope of authorization granted.

Client : 3rd party applications that want to access user accounts. Before it can do so, the resource / authorization server and the resource owner must authorize the request. All clients must be registered with the authorization server and will be provided with their own unique credentials (client_id and client_secret) for separate authentication.

Authorization Server (usually the same as the Resource Server): Sometimes, you may want to pull out the authorization server from the resource server and deploy it as a dedicated version, especially in distributed environments.

Take an example like this:
When you log in with Facebook or Gmail, the website will take you to the Facebook page (or software) and list the permissions it needs to allow you to log in and use the service. If we agree, then at this time Facebook will give the website a token Token that contains certain rights to help the website can verify who we are as well as make the website work. If this website is hacked, it will only get information or our activities on that website without affecting the other websites that are being used. So this way of logging in using OAuth method is very safe for end users like us.

Flow diagram of OAuth2

1. The application (website or mobile app) requires authorization to access the Resource Server (Gmail, Facebook, Twitter or Github …) through the User
2. If the User authorizes the request, the Application will receive authorization from the User (in the form of a token string)
3. The application sends its identification information (ID) with the authorization of the User to the Authorization Server
4. If the identity information is validated and authorized, the Authorization Server will return to the access_token Application . At this point the authorization process is complete.
5. To access resources from the Resource Server and retrieve information, the Application will have to give access_token for authentication.
6. If access_token is valid, Resource Server will return the data of the resource requested for the Application.

Above is what I learned about the methods when performing authentication rest api. Hope the article helps people!

Reference

https://medium.com/security-operations/what-is-oauth-and-why-should-i-use-it-5aa2f27ce387
https://blog.restcase.com/4-most-used-rest-api-authentication-methods/
https://habr.com/en/post/449182/
https://dzone.com/articles/four-most-used-rest-api-authentication-methods