API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX API Connectivity Manager authentication and NGINX Single Sign-on.

Introduction

API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX Management Suite API Connectivity Manager authentication and NGINX Single Sign-on.

This separate article will cover the different authentication types and how they work with clients and servers.

API Authentication and Authorization

It may sound a bit basic, but getting back to the basic concepts help us understand, innovate and develop more secure designs.

Authentication, is the act of validating that users are whom they claim to be.

Authorization, is the process of giving a user the permission access/ perform specific function.

Below, we will explore the different API authentication types,

Basic Authentication.
API Key Authentication.
Bearer Authentication.
Open Authorization (OAuth 2.0).
OAuth Token Introspection.
OpenID Connect (OIDC).

Basic Authentication

HTTP Basic authentication, is a method for user agent (e.x Browser) to provide credentials to a web server. The request contains a specific header to provide base64 encoded credentials.

Credentials are already shared with the clients before clients can access the server using this method.

Example,

Authorization: Basic <credentials>

\n\n

API Key Authentication

An API key is a token that a client provides when making API calls. not to conflict this method with secure tokens generated via OAuth, in this type, the API keys are generated whether at the application or API key server, then those keys are distributed to the clients to be used for accessing the application.

API Key can be inserted in different location in the HTTP request,

As a Query parameter in the HTTP request URL.
As a Request header.
As a Cookie.

\n\n

Bearer Authentication

Bearer Authentication can be considered an early step to token authentication mechanisms, it depends on initial users credentials to validate them and issue a time limited token for a specific service.

User provides credentials over POST request to the server.
The server validates the credentials and provides a token with expiry date/time to the user.
The server then validate future requests to check the token validity and provide response based on that.

\n\n

Open Authorization (OAuth 2.0)

At first sight, the question might be why we are referencing authorization yet we are discussing authentication.

Let's check the basic definition, OAuth is an open standard for access delegation, commonly used for internet users (untrusted medium) to grant websites (resource server) access to user information at other websites (OAuth authorization server) without providing their passwords.

Performing Authentication via OAuth can be referred to as (Pseudo-authentication),and it's very similar to OIDC Authentication approach which will be discussed in the following section.

User request a resource or a site login.
The site sees that the user is not authenticated, It formulates a request for the identity provider, encodes it, and redirect the user to the identity provider.
The user's browser makes a request to the redirect URL for the identity provider, including the application's request
Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and redirect the user browser back to the application.
The user's browser requests the redirect URL that goes back to the application, including the identity provider's response.
The application decodes the identity provider's response, and carries on accordingly.
(For OAuth) The response includes an access token which the application can use to gain direct access to the identity provider's services on the user's behalf.

\n\n\n

OAuth Token Introspection

In the previous section, we explored the idea of OAuth token authentication, and using API gateway whenever it recieves a request it starts the redirection process to the Identity provider and receive the SAML insertion response back that verifies the user and then the user is allowed to access a protected resource.

In Token introspection, API gateway receives the token from the OAuth client and communicate with the Authorization server to query meta information regarding the presented token for example (If the token still active, the access privilege and the authorization context).

\n\n\n

OpenID Connect (OIDC)

OpenID is an open standard for decentralized authentication, It allows authentication by (Relying sites) using third-party providers (Identity Providers) to eliminate the need for application owners to create their own login systems and allow the users to use different applications without passing their credentials over internet to different entities.

OIDC is built on top of OAuth2.0 framework, that explains the common parts we can see between both frameworks.

\n\n\n

The main difference observed between OAuth vs OIDC can be explained in the following example,

OIDC Auth:\n
- The user request access to an application.
- The application reply with a question, who is this user ?
- The user is redirected to an identity provider to certify that this is a valid user and issue relevant token.
- The user redirected back to the application with the obtained token.
\n
OAuth authentication\n
- The user request access to an application.
- The application reply with a question, Do you have access key ?
- The user is redirected to an identity provider to get a key to obtain access to the application.
- The user redirected back to the application with the obtained key.
\n

In this article, we went through the common API Authentication types, the following articles will cover use cases for API authentication whether directly through NGINX Plus or API Connectivity Manager.

\n\n

References

OAuth protocol

OAuth Token introspection

OpenID Connect

NGINX Plus

NGINX Management Suite API Connectivity Manager

Introduction

API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX Management Suite API Connectivity Manager authentication and NGINX Single Sign-on.

This separate article will cover the different authentication types and how they work with clients and servers.

API Authentication and Authorization

It may sound a bit basic, but getting back to the basic concepts help us understand, innovate and develop more secure designs.

Authentication, is the act of validating that users are whom they claim to be.

Authorization, is the process of giving a user the permission access/ perform specific function.

Below, we will explore the different API authentication types,

Basic Authentication.
API Key Authentication.
Bearer Authentication.
Open Authorization (OAuth 2.0).
OAuth Token Introspection.
OpenID Connect (OIDC).

Basic Authentication

HTTP Basic authentication, is a method for user agent (e.x Browser) to provide credentials to a web server. The request contains a specific header to provide base64 encoded credentials.

Credentials are already shared with the clients before clients can access the server using this method.

Example, Authorization: Basic <credentials>

API Key Authentication

API Key can be inserted in different location in the HTTP request,

As a Query parameter in the HTTP request URL.
As a Request header.
As a Cookie.

Bearer Authentication

User provides credentials over POST request to the server.
The server validates the credentials and provides a token with expiry date/time to the user.
The server then validate future requests to check the token validity and provide response based on that.

Open Authorization (OAuth 2.0)

At first sight, the question might be why we are referencing authorization yet we are discussing authentication.

Performing Authentication via OAuth can be referred to as (Pseudo-authentication),and it's very similar to OIDC Authentication approach which will be discussed in the following section.

User request a resource or a site login.
The site sees that the user is not authenticated, It formulates a request for the identity provider, encodes it, and redirect the user to the identity provider.
The user's browser makes a request to the redirect URL for the identity provider, including the application's request
Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and redirect the user browser back to the application.
The user's browser requests the redirect URL that goes back to the application, including the identity provider's response.
The application decodes the identity provider's response, and carries on accordingly.
(For OAuth) The response includes an access token which the application can use to gain direct access to the identity provider's services on the user's behalf.

\n\n

OAuth Token Introspection

\n\n

OpenID Connect (OIDC)

OIDC is built on top of OAuth2.0 framework, that explains the common parts we can see between both frameworks.

\n\n

The main difference observed between OAuth vs OIDC can be explained in the following example,

OIDC Auth:\n
- The user request access to an application.
- The application reply with a question, who is this user ?
- The user is redirected to an identity provider to certify that this is a valid user and issue relevant token.
- The user redirected back to the application with the obtained token.
\n
OAuth authentication\n
- The user request access to an application.
- The application reply with a question, Do you have access key ?
- The user is redirected to an identity provider to get a key to obtain access to the application.
- The user redirected back to the application with the obtained key.
\n