SBN

Common REST API Authentication Methods Explained

When it comes to implementing automation and orchestration, it is critical to understand how authentication works with APIs. The majority of the products in your environment likely have some sort of authentication mechanism. You need to know the nuances and differences between various authentication methods in order to automate communications with those APIs. In this blog post, I aim to help you understand by breaking down three different API authentication methods.

Username & Password Authentication

One of the most common authentication methods used by REST APIs is username and password authentication. There are several different types that use a username and password but the most common one is HTTP Basic authentication. It’s straightforward if you are experienced with APIs but can be challenging for beginners to understand how it works and how to use it.

Per RFC2617, making an HTTP Request using Basic authentication requires a base64 encoded string that consists of a username and password combined together with a colon.Once this is done it is prepended with the string `Basic` plus a single space. To make this a little more clear, let’s look at the following example:

Username: first.last

Password: my5uper5ecretP@ssw0rd

Imagine you have a username and password like the above example. To use these as part of an HTTP Request to an API you must first combine them with a colon:

first.last:my5uper5ecretP@ssw0rd

Once that is done then they need to be base64 encoded. In Python you could do the following:

import base64
auth_string = base64.b64encode(b':'.join(('first.last'.encode('latin1'), 'my5uper5ecretP@ssw0rd'.encode('latin1')))).strip()

If you printed our auth_string variable you would receive the following value:

b’Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ=’

Now that you have this encoded string, you then prepend the authentication method string (which is Basic) to this variable. The entire variable string should be as follows:

Basic Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ=

Once this string is created then it is added to a specific HTTP Header in your HTTP Request. This header is special and is used for authentication. If you haven’t guessed it yet, the header is called Authorization. Handy, right?

Here is an example cURL command using basic authentication:

AUTH=$(echo -ne "$BASIC_AUTH_USER:$BASIC_AUTH_PASSWORD" | base64 --wrap 0)

curl \ 
--header "Content-Type: application/json" \ 
--header "Authorization: Basic $AUTH" \ 
--request POST \ 
--data '{"key1":"value1", "key2":"value2"}' \ 
https://example.com/

JWT Authentication

JWT (JSON Web Token) authentication is a common form of token authentication based on RFC 7519. JWT authenitication is made up of three main parts: a Header, Payload, and Signature. Each of these parts is base64 encoded and sent along with an HTTP Request for authentication.

A JWT claim set is made up of one or more claims which are specified in a JSON object. Each claim in a set of claims has a unique key and a corresponding value. For example, the typical structure of a JWT claim set is:

{

“iss”: “josh”,

“exp”: 1617221146,

“https://api.mycompany.com/some...”: true

}

Each key and value must be unique and are considered an individual claim being made within the claim set. Each of these specified keys is arbitrary and is not required by the RFC standard. This means that the structure of the claim set in JWT authentication is up to the API / service you are working with.

Just like the Header and Signature values, once you have your JWT claim (payload) defined then it is base64 encoded. You can test these values out on https://jwt.io as well.

OAuth2 Authentication

OAuth2 authentication is becoming extremely popular for the simple fact that it supports many different ways (flows) to authenticate to the same endpoint(s). This helps developers build robust services that enable authorization for different situations like authenticating as a web application, desktop application, mobile device, etc. by simply changing a few details instead of supporting an entirely different authentication mechanism for each one.

To help understand the concepts of OAuth2 authentication, I created this diagram that shows the four core components:

  1. A user or system that is needing access

  2. A server that is responsible for authorization

  3. An application that is granted access via the authorization server

  4. That application then accesses data based on that authorization

OAuth2 authentication diagram

If you would like to know more about OAuth2, then please check out the three-part series I wrote explaining OAuth2 in more detail here:

When looking at authentication types, OAuth2 and JWT are more secure than Basic and you will likely come across both of these when using APIs, especially when working with products like EDR, SIEM, etc.

There are many other types of REST API authentication as well as variations of the methods listed above but I hope this helped you understand the three most common authentication methods used by APIs.

*** This is a Security Bloggers Network syndicated blog from Swimlane (en-US) authored by Josh Rickard. Read the original post at: https://www.swimlane.com/blog/common-rest-api-authentication-methods-explained-2/