HTTP Authentication
When working with HTTP-based APIs, you must ensure that you authenticate properly. Some APIs are simple and use an Authorization: Basic header with a username and password while others use OAuth or Bearer tokens.
Username and Password
The simplest type of authentication is a username and password. This method usually uses an Authorization: Basic header containing the username and password concatenated with a colon (:) and then base64 encoded. Here is an example:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Automation will encode that for you. To use an API with a username and password, you must:
- Create an account key using the HTTP Basic Authentication type with your username and password.
- Configure your target to use the account key.
- Use the target with the HTTP Request activity. Automation will handle the Authorization header for you.
Bearer Token
Most modern APIs use some sort of bearer token/JWT for authentication. These are self-contained and signed tokens that can be validated without needing to consult an identity server (more information about JWTs). In Automation, we do not have an account key type for these because they are usually only valid for 10 to 30 minutes before you have to request a new one.
When using bearer tokens, you usually need to make an HTTP Request to get a token and then use the token for subsequent requests. In Automation, we do this by having two targets and one account key.
Target A - with Account Key
The first target uses an account key with the credentials necessary to request a bearer token. This is usually a HTTP Basic Authentication account key with a client ID for the username and client secret for the password. You can use the HTTP Request activity with this target to request a bearer token. The token response is commonly JSON that contains the token itself as well as how long the token is valid for.
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpX...",
"token_type": "bearer",
"expires_in": 600,
"scope": "integration private-intel admin profile enrich:read sse registry users casebook inspect:read orbital oauth response ui-settings telemetry:write notification global-intel:read"
}
To extract the token, you can use a JSONPath Query activity with a path of: $.access_token.
Target B - No Account Key
Once you have your bearer token, you can make API requests without an account key as you will be using the token for authentication. When using this target with the HTTP Request activity, you need to provide the bearer token in a custom header:
Static API Key or Token
If your API uses a static key or token that does not change, you can store it in a Secure String variable and add it to the HTTP Request using a custom header (see Target B - No Account Key). This variable can be global or contained within the workflow itself.
OAuth
Typically, authentication with OAuth-based APIs is a two step process:
-
Using a client ID and secret, fetch an access or bearer token from a token endpoint (for example, https://cool-api.somewhere.com/oauth2/token). The client ID is usually used as the username for HTTP Basic authentication and the client secret is used as the password.
-
Use that access or bearer token for all subsequent requests to the API (for example, https://cool-api.somewhere.com/api/awesome-data). The token obtained from Step 1 is usually put in an Authorization header with the word Bearer (for example, Authorization: Bearer my-long-token-here).
-
Refresh the access or bearer token as needed; this will depend on how the specific API is implemented.
Automation does not support following OAuth authorization or grant flows. If your API requires you to follow a web-based authorization flow to give an API client permission to a resource, you’ll need to do that yourself and then use the resulting client ID, secret, or tokens within Automation. OAuth implementations vary, so we’re only able to document some generic guidelines. Please refer to the individual product’s API documentation for more information about how to authenticate properly.