OAuth2

A guide on how to implement an OAuth2 flow for authenticating to our REST APIs.

Overview

This guide aims to provide the basic understanding and ability to authenticate a Service Account for REST API integrations. Core concepts about the OAuth2 authentication flow are briefly explained, and an example implementation is provided. The implementation is tested using the returned access token to send a request to the REST API to list all available spaces.

Our OAuth2 implementation is based on the RFC7523 specification

Migration Guide

Key Changes

The following changes have been made to ensure RFC7523 compliance:

  1. JWT Claims (Required):

    • aud (Audience): Must be set to the token endpoint URL (https://app.neowit.io/api/auth/oauth/token)

    • iss (Issuer): Must be set to your service account ID

    • sub (Subject): Must be set to your service account ID

  2. Response Body Format:

    • The response now uses snake_case field names per OAuth2 specification

    • Changed from accessToken to access_token

    • Added token_type field (value: "Bearer")

    • Added expires_in field (lifetime in seconds, maximum 3600)

  3. Algorithm Support:

    • Only HS256 algorithm is supported

    • Ensure your JWT header specifies "alg": "HS256"

Migration Checklist

To migrate your existing implementation:

Prerequisites

A Service Account must be created in the organization before continuing.

Example

The example code in this page is provided as is, it may not work in your environment and should be used as a quick guide for implementation rather than code to be used in a production environment.

Environment Setup

If you wish to run the code locally, make sure you have a working runtime environment.

The following packages are required by the example code and must be installed.

Source code

If you wish to run the code locally, make sure you have a working runtime environment.

The following packages are required by the example code and must be installed.

Code walkthrough

Authenticating a client is a 3 step process which can be summarized by the following points. Each step will be detailed more below.

  1. A JWT is constructed and signed with a secret.

  2. The JWT is exchanged for an Access Token.

  3. The Access Token is used to authenticate with the REST API.

1. Create the JWT

In general, a JWT contains three fields:

  1. Header: Token type and signature algorithm.

  2. Payload: Claims and additional data.

  3. Signature: A signature calculated of the entire JWT, using a private secret.

Before being sent, these fields are each Base64Url encoded. They are combined in a compact dot format in the form Base64Url(header).Base64Url(payload).Base64Url(signature), which is what we will refer to as the encoded JWT.

This guide will not cover much more details of JWT. For a great introduction on JWT that provides an interactive editor and an exhaustive list of client libraries, please see jwt.io.

Using your Service Account credentials, construct the JWT headers and payload. Here, iat is the issuing time, and exp the expiration time of a maximum 1 hour after iat.

The simplest way of Base64-encoding and signing our JWT is to use some language-specific library. This is available in most languages but can be done manually if desired.

2. Exchange for Access Token

The encoded JWT is exchanged for an Access Token by sending a POST request to the same endpoint used to construct the JWT, namely https://app.neowit.io/api/auth/oauth/token.

The POST request header should include a Content-Type field indicating the format of the body. Additionally, the POST request body is Form URL-Encoded and contains the following fields:

  1. "assertion" - Contains the encoded JWT string.

  2. "grant_type" - Contains the string "urn:ietf:params:oauth:grant-type:jwt-bearer". This specifies that you want to exchange a JWT for an Access Token.

It is important to note that the data has to be Form URL-Encoded. Like Python's requests, some libraries do this by default and require no further input by the user. This is, however, not the norm and likely requires an additional step before sending the request. The URL Form Encoded data should have the following format.

The header, payload, and signature are found in the previous step.

The Access token response will have the following format and will be valid for 1 hour. To refresh the token, repeat the above steps.

3. Access The REST API

Once you have the Access Token, you need to include this with every call to the API. This can be achieved by including the Authorization header in the form shown in the snippet below.

The Access token response will have the following format and will be valid for 1 hour. To refresh the token, repeat the above steps.

Refreshing the Access Token

The access token retrieved using the process above needs to be refreshed every hour. This may be done by intercepting the 401 http response code, or by checking if the expiry time is getting close before performing each REST API call.

Last updated