Cookie consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Authorization settings

Last updated: May 15th, 2024

The Authorization settings tab allows you to define the type of authorization used by integration requests (in both request and polling phases). Please follow our step-by-step guide below or watch our video to find out more.

The following options are available in the authorization type dropdown which are:

No Auth 

Using this option means there is no authorization required by requests, alternatively you can select ‘No Auth’ and choose to put your authorization in your request header in the Request tab.

Token Auth

This option defines an authorization token to be sent with the request. 

Enter the following information into the appropriate fields:

Token type: specify the type of token e.g. Bearer.

Token: the token string

OAuth

OAuth is an open industry standard for access delegation and can be used by the Cutover application to access information in any OAuth compliant service.

Following a standard process, a user must first provide authorization by signing into the third party service with the user’s credentials. With this authorization, Cutover will then obtain and store an access token that is subsequently used to perform API calls on the user’s behalf. The Custom Integration OAuth tab provides the necessary fields to enable OAuth for a compliant service.

The following settings are defined by an OAuth provider. To find the appropriate settings for the service you would like to access, visit the OAuth documentation for that service.

First select the OAuth Flow type:

Authorization Code: A commonly used OAuth flow where an authorization code is exchanged for a token.

Client Credentials: Involves an application exchanging its application credentials, such as client ID and client secret, for an access token. This flow will display a subset of the configuration settings described below.

Now inform the OAuth settings:

Requires Client Assertion: Toggle if your OAuth provider requires a client assertion before requesting an access token. Only relevant to 'Authorization Code' flow.

Client ID: The ID provided by the third party OAuth provider.

Client Secret: The secret associated with the client ID.

OAuth2 provider host: This is the base URL for the OAuth provider (e.g. https://login.microsoftonline.com)

Authorization endpoint: The endpoint defined by the OAuth provider to perform authorization (e.g. /common/oauth2/v2.0/authorize). Only relevant if you selected the 'Authorization Code' flow type.

Token endpoint: The endpoint defined by the OAuth provider to exchange the authorization token for an access token (e.g. /common/oauth2/v2.0/token)

Scopes: The types of operations that Cutover will be allowed to perform on behalf of an authorized user. Scopes are defined by the OAuth provider and usually allow restricted permissions to certain functions (e.g. read, write, profileAccess, etc.)

The last setting is the only one defined by Cutover:

Redirect URI: The URI that the OAuth provider must redirect to after the authorization step, where [instance] is the base URL for your Cutover instance. Only relevant to 'Authorization Code' flow.

[instance]/api/integrations/oauth/authentications/payload_transformer/callback

Once all settings are completed, it is now possible to authenticate with the OAuth provider in order to perform the API calls defined by the integration. There are two kinds of authentication: as a functional user or individually at the task level.

Authenticating as a functional user

When authenticating as a functional user, the user’s credentials are supplied for all workspaces of the integration. To authenticate as a functional user, click on the “Authenticate“ button in the OAuth tab of the Custom Integration.

Once this is done, it will look like this: 

If the functional user is not defined, the integration will request that the authentication be done at the task level.

Authenticating as a task user

The second form of authentication is in every instance of the integration, for example, in the task edit panel of a runbook with an OAuth enabled Custom Integration. When a functional user has not been defined, the “Authenticate“ button is displayed in the task edit sidebar panel. Click this button to authenticate with the OAuth provider. The integration will use these credentials to perform API calls.

AWS STS SigV4

The “AWS STS SigV4“ type uses AWS STS (Secure Token Service) to perform authorization.

Enter the following information into the appropriate fields:

AWS Service Code: The STS service code.

External ID: The AWS external ID.

Role ARN: The AWS role ARN.

Region: The AWS region.