Backend/Auth: A concise summary of API Authentication types - Part 1

#productivity #programming #beginners #architecture

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

## Table Of Contents
* Introduction
* Types of Authentication

Introduction

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:

Types of Authentication

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

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.

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: