Backend/Auth: A concise summary of API Authentication types - Part 1
Tags: productivity, programming, beginners, architecture
Published: 2022-03-06 18:44:00

Hey folks! In this article (part 1) and the upcoming article (part 2), I will cover and **summarise** the types of mostly used authentication generally used for API/Backend development and as per [RFC](https://www.ietf.org/standards/rfcs/) 

 ## Table Of Contents
     * [Introduction](#chapter-1)
     * [Types of Authentication](#chapter-2)

### Introduction <a name="chapter-1"></a>

#### What is Authentication & Authorization?

Authentication is the process of proving your identity using credentials) and Authorization is the process of granting limited access based on user role.

The authentication process is primarily based on 2 things: 
**What user know (PWD) + What user have (OTP/MFA_TOKEN/API_TOKEN)**

> Notation I am using below, **(NO, YES)** means a type of Authentication process that doesn't require a user to know anything (NO) but requires the User to have something (YES) respectively. PFA for a quick summary:

![Quick summary](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k64isul3sn0vg8edgtkh.png)

### Types of Authentication <a name="chapter-2"></a>

#### TYPE 0: No Auth (NO, NO)
A Google search page doesn't require the User to know anything and to have anything. 
***

#### TYPE 1.1: Basic Authentication (YES, NO)
A simple way of proving your identity is which a User is required to know something (PWD) but doesn't require to have anything.

A general use case is a Gmail login. however, it is comparatively less secure so it's always HTTPS recommended.

#### TYPE 1.2: Digest Authentication (YES, NO)
A digest way of proving your identity. This is a combination of Basic Authentication along with extra security by Base64 encoding of Username & Password as an extra layer of encryption thus security. 

** This Base64 encrypted username + password combined called Digest**. This can be then supplied as an `Authentication header`.
***

#### TYPE 2: API Key/Token Based

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ih342wxwudlg2vlq0o7z.png)

#### TYPE 2.1: API_KEY (NO, YES)

This is another type of Authentication where an API_Consumer/Client doesn't require to know anything but to have something (API_TOKEN/API_KEY) to prove the identity.
 
Example: Accessing web-hook/service endpoints by having the API_TOKEN. This is in the context of not referencing an actual user instead of considering a Client Application/Consumer authentication to access a 3rd party Service. 

The API_TOKEN can be supplied as `x-API-key` as Authentication header OR as a `query parameter` also. An example of this type of Authentication is to accessing a Google Geolocation API inside of an Application Client or accessing an ML API by downstream apps.

#### TYPE 2.2: BEARER TOKEN (NO, YES) ~ OAuth 1.0
Similar to the above type but consider this as a Frontend application accessing a downstream Backend application by passing a **JSON token a.k.a Bearer Token**.

This is a very popular approach if the Frontend and Backend of an application are decoupled while maintaining a **Stateless / Soft Authentication** practice for the User.

![OAuth 1.0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/78fb6iiws4u9i6e3wj0z.png)

##### Downside of this type of authentication:

- The downside of this approach is that API_TOKEN can be compromised easily as a turnaround and best practice these tokens are encrypted using `PRIVATE_KEY`. 

Furthermore, these tokens are generated with an `expiry` as well as an extra security check but this calls for re-authentication which hamper the user experience.

- Another drawback is this can only be extended to **Web Workflows** and thus does not solve the problem of Password Anti Pattern and better separation of duties/Authorization across different micro-services. More on this I will cover in part 2 of this article.

The above drawbacks call out for `OAuth 2.0` which is a complete rewrite of `OAuth 1.0`. I will be covering this in part-2 of this article.
***

#### TYPE 3: Two Factor/Multi-Factor Authentication (YES, YES)
The most secure way of authentication require the User to know something (PWD) and to have something (OTP or MFA code)

A common use case can be found for applications that can not afford compromise on security like Banking applications etc.
***

#### TYPE 4: Mutual SSL/Certificate based authentication/2 way SSL/2-legged authentication (all are same :))
This is also a type of authentication which is highly a secure type of authentication. This refers to two parties authenticating each other by providing a digital certificate `cert.key` so that both parties are assured of the other identity over L4 (Layer 4) Security.

Based on the level of security this approach is also a preferred approach of authentication b/w API_Consumer/Client and the Server for data-sensitive applications.

As there are several types of Authentication available understanding them can be overwhelming. Hope this summarisation helps the `DEV Community`.

Thats all for the part 1!

---

Connect 🤝:
Email: bbhopalw@gmail
Linkedin: www.linkedin.com/in/bbhoaplw

---

For further reading ✍️:
Big Data & Cloud Engineering blogs:
* Towards Data Science & AV Publication: https://medium.com/@burhanuddinbhopalwala

Backend & Software Engineering blogs:
* DEV Community: 
https://dev.to/burhanuddinbhopalwala