Authenticating your system with an OAuth API key is our recommended auth method. Review our authentication overview.
- A user must be assigned to an engineer role to manage OAuth API keys. Learn about user roles.
- If using your own private/public key pair, generate your own key pair.
- If using your own application for sending the auth request, make sure the axios and jose libraries are installed with npm i axios jose.
First, here’s a high-level overview of the authentication flow:
- Provide your own or generate a public key with Redox.
- Send an auth request for an access token from Redox, then store the access token in your system.
- Initiate any API request with the access token in the header.
Check out the diagram for a visual version of these steps:

First, you have to have an API key with a private/public key pair. There are two options for this step:
- Option 1: Generate a private/public key pair in the Redox dashboard.
- Option 2: Provide your own public key to Redox and store your own private key.
The navigation steps are the same, but there are separate steps for each method provided below.
- Log in to the dashboard.
- From the navigation menu, select the Developer page.
- By default, the Sources tab opens and displays any configured sources and OAuth API keys. Click the New OAuth API key button. If you want to configure an existing OAuth API key, click the Edit button next to it. Then skip to step 6.
- A modal opens with the API key details. In the Name field, enter the API key name.For multi-region organizations
- Click the Add button.
![A user creates a new OAuth API key in the Redox dashboard. A user creates a new OAuth API key in the Redox dashboard.]()
Create an OAuth API key - The Settings page opens with the API key details:
- The Name field contains the API key name you entered previously. Click the Rename button to change it.
- The Client ID field shows the automatically generated ID for the API key. Copy and store the client ID to use when sending an auth request.
- Choose one of the following options for your key pair:
Next, send an auth request to receive an access token from Redox. The auth request steps are the same, but there are two options for completing them:
- Option 1: Use an application of your choice.
- Option 2: Use our Postman collection (You must complete the prep steps first).
- Generate a signed request in your system using your private key.
- Copy the relevant code example for the auth request. Check out the header and parameter definitions below these steps for expected values.
- Option 1: With your own application, the auth request should look like one of these:For JavaScript, update the privateKeyPEM, clientId, and kid based on the signed request you generated in step 1.Prerequisite: Install axios and joes librariesExample: Auth request for OAuth (JavaScript)javascriptFor Python, update the clientId, and kid based on the signed request you generated in step 1, then save your private key in a file named private_key.pem in the same directory as your script.Example: Auth request for OAuth (python)python
- Option 2: With Postman, the authentication request should look like this:Example: Auth request for OAuth (cURL)bash
- Send the populated auth request with the signed assertion to https://api.redoxengine.com/v2/auth/token via HTTP POST from your system.
- Redox validates the signature in the request using your public key, then sends back a response with the access token.
- Store the access token in your system.Expiration for access token
Review the definitions and expected values for the JWT head and body. Or, view an example of a valid JWT with all of these values populated.
For the JWT header, you should use content-type application/x-www-form-urlencoded and these values:
Parameter | Required | Description |
|---|---|---|
alg | Y | The JSON Web Alorgithm (JWA) used for signing the authentication JWT. We currently only support RS384 and ES384. |
kid | Y | The identifier of the key-pair used to sign this JWT. This identifier tells us which public key to use to verify the JWT. |
typ | Y | The type of token request. Populate this with JWT. |
jku | N | This field may be populated if you provided a JWKS URL in the Redox dashboard. If you provide it here, the URL should match what’s saved in the dashboard. Populate this with the TLS-protected JWKS URL, which contains the public key(s) that are accessible without authentication or authorization. If this field isn’t present, Redox reverts to what’s saved in the dashboard. |
For the JWT body, use all these required parameters:
Parameter | Required | Description |
|---|---|---|
iss | Y | The issuer of the JWT. Populate this with the client_id of the key you created in the dashboard (in the Settings page of the OAuth API key). The iss and sub contain the same values. |
sub | Y | Populate this with the client_id of the key you created in the dashboard (in the Settings page of the OAuth API key). The iss and sub contain the same values. |
aud | Y | The audience of the JWT. Populate this with https://api.redoxengine.com/v2/auth/token. |
iat | Y | The UTC timestamp for when the JWT was created (e.g., 1970-01-01T00:00:00Z UTC). This time must not be greater than 5 minutes before exp. |
exp | Y | The expiration UTC timestamp for the JWT (e.g., 1970-01-01T00:00:00Z UTC). This time must not be greater than 5 minutes in the future. |
jti | Y | A nonce string value that uniquely identifies the JWT. Redox denies requests if you attempt to reuse the jti within the lifetime of the JWT. |
For the HTTP request body, use all these required parameters:
Parameter | Required | Description |
|---|---|---|
grant_type | Y | Populate this with client_credentials. |
client_assertion_type | Y | With your own application, populate this with urn:ietf:params:oauth:client-assertion-type:jwt-bearer. With Postman, this value automatically populates when you download the Postman collection. |
client_assertion | Y | With your own application, populate this with the signed assertion you generated with your private key. With Postman, this value automatically populates. |
Now you’re ready to initiate API requests with the access token in the Authorization HTTP header using the Bearer authentication scheme like this:


