Configuring Integration Credentials

OneTrust supports a number of seeded and custom credential types for external system integration. Read this article to learn more about the supported integrations, authentication methods, grant types, and possible fields you may see when creating credentials for use with OneTrust Integrations.

To create credentials

When you select your desired system, the OneTrust application can populate fields for many systems with their most commonly used credential type(s) and related fields to assist with configuration. In addition, you can test the connection status of the credential when editing the credential details.

Note:

Not all systems will be supported with auto-populated fields.

  1. On the Integrations menu, select Credentials.

    The Credentials screen appears.

  2. Click the Add credential button.

    The Select existing system screen appears.

  3. Enter your system in the Select System field, then click the Next button.
    Note:

    For the purposes of this documentation, we are choosing Generic to show the Application type options.



    The Enter Credential Details screen appears.

  4. The Enter Credentials Details screen will populate default fields relevant to the chosen system's available configuration type. Examples:

    • Okta: API Key

    • Amazon S3: AWS

    • Google BigQuery: OAuth 2.0 JWT

  5. Changing the Configuration Type field to Configure manually will populate additional Application Type fields for customization.


  6. Refer to the table below for all possible options.


    Application Types

    Description

    Web App

    Web app integrations can securely integrate systems using HTTPS protocol. For more details on web app fields, see Web Apps Fields and Supported Web App Authentication Methods.

    Encryption

    OneTrust currently supports Pretty Good Privacy (PGP) to encrypt files uploaded to servers via SFTP actions. For more information, see Using Pretty Good Privacy (PGP) in Integration Workflows.

    File Share

    File sharing actions can pass files securely to and from servers using a trusted integrations authenticated by a combination of methods, which may include password, public key, and PEM formatted private key. For more information on generating keys, see Generating RSA Keys for SFTP Authentication in OneTrust Integrations

    Database

    Connect directly to a database. Requires specific details such as host, username and password, name, and port. For more information see Database Credentials.

    Decryption

    OneTrust currently supports Pretty Good Privacy (PGP) to decrypt files downloaded from servers via SFTP actions. For more information, see Using Pretty Good Privacy (PGP) in Integration Workflows.

    Cloud SDK

    Cloud SDK connector types can create secure integrations between your chosen cloud platform(s), such as AWS and Azure.
  7. The Test settings (recommended) section lets you test an URL to verify the credentials before saving and using them. Provide your URL and click the Test Credentials button.


    If the credential cannot be verified, a detailed error message will appear with codes and status details to help you troubleshoot.



    Note:

    OAuth 2.0 authentication credentials cannot be tested.

  8. Use the Classify as sensitive setting to indicate if these credentials will be used in a sensitive workflow. Only users with "Manage Sensitive Classification" permissions will have access.
    Note:

    In order to use a sensitive credential or workflow, both items must be classified as sensitive. For more details, see Classifying Integrations as Sensitive.

  9. Complete the fields, then click the Save button.

To test credentials after creation

  1. On the Credentials screen, click the Context Menu of your newly created credential, then select Edit.

    The Credential Details screen appears.

  2. Click the Test Credentials button in the Credential Status block. The application will test the connection of the credential and return a status.
    Note:

    Not all credential types support testing.



  3. The application will test the connection of the credential and return a status.


  4. If the test fails, the application will return an error code and a message to describe the failure.


To edit credentials

  1. Open the Context Menu of a credential and click Edit.

    The Credential Details screen appears.

  2. Click the Edit icon next to the respective fields to update the credential as necessary.
  3. Click the Save button.

To delete credentials

  1. Open the Context Menu of a credential and click Delete.

    The Delete Credential modal appears.

  2. Click the Delete button to permanently delete the credential.

Web Apps Fields

The table below lists the possible fields which may populate based on the system selection.

Field
Description
Credential Name

Enter a name to identify the credentials.

Description

Enter a description of the credentials.

Application type

Select Web App.

Authentication method

Select the applicable authentication type required for your web app integration (e.g. OAuth 2.0). For more information on these types, see Supported Web App Authentication Methods.

Protocol

Defaults to HTTPS.

Hostname

Enter the hostname for the credential. When a credential is associated to a workflow action, the hostname will be the default domain for this action. If a previous domain has been specified on the action, the hostname will replace that domain.

Test URL

Enter a test URL for the new credential.

OneTrust recommends using the Test Credential feature to validate TEST URL field.. This is a valid REST GET URL provided by the attempted system integration. For more information, see Testing Workflow Actions and Saving Sample Payloads.

Key (Default Header)

Select the type of key which should be used in the header of the call made by the connection.

You can add additional keys if your credential requires more than one header.

Value (Default Header)

Enter the value of the key which should be used in the header of the call made by the connection.

User name

Required for Basic authentication.

Password

Required for Basic authentication.

Access TokenRefresh Token

Provide a token value for the credential.

Note:

OneTrust supports masking of the Access, Refresh and Bearer tokens. Once the values are generated and saved, they cannot be retrieved from the interface.

If a token is provided by the user, OneTrust will save that token to the credential and call the token endpoint when that access / refresh token expires. If no value is provided by the user during credential creation or when editing the token, OneTrust will call the token endpoint to retrieve an access token.

Send credentials in

Choice of HTTPS Headers or XML Envelope.

Allow mTLS

Enable mutual transport layer security (mTLS) for all credentials using the Web App connector type to establish secure and trusted integrations with external servers. This only applies to outbound integrations made by actions in integration workflows which use this credential type.

For more information, see Setting Up Mutual Transport Layer Security.

Server Certificate Chain

Post a custom server certificate to any HTTPS credential to establish a secure and trusted connection with external systems not using a certificate issued by a trusted authority.

OAuth 2.0 token reuse and retry behavior

OneTrust may reuse a cached OAuth 2.0 access token for integration workflow actions. The cache lifetime can be shorter than the access token lifetime reported by the token issuer.

If the receiving system rejects a cached token as expired or invalid, OneTrust may obtain or use a new token and retry the action. The receiving system may record the failed first attempt even when the retry succeeds.

These authentication and exception entries may be generated in the receiving system's logs rather than in the OneTrust application. If the payload is delivered successfully but the receiving system records repeated token failures, review that system's retry, exception, and alert-logging settings. Contact OneTrust Support if the retry does not deliver the payload, data is lost, or the action remains unsuccessful.

Supported Web App Authentication Methods

Authentication Method

Description

Basic Authentication

This authentication method only requires a username and password.

Bearer Token

This authentication method requires an authentication token generated by the external system.

Note:

OneTrust supports masking of the Access, Refresh and Bearer token. Once the values are generated and saved, they cannot be retrieved from the interface.

OAuth 2.0

This authentication method requires a secure connection shared between OneTrust and the given system account or instance. There are a number of supported grant types and applicable fields unique to these option.

For more information on these grant types, see Using OAuth Grant Types in OneTrust Integrations.

For more information on Proof of Possession (POP) tokens, see Generating POP Tokens for OAuth 2.0 Credentials.

For more information on authentication options, see Custom Authentication Options for OAuth 2.0 Credentials.

API Key

This authentication method requires a provision of an API key with an applicable value. You will also need to specify its authentication parameters either sent via the request or the headers.

Custom

Create and configure custom credentials to account for your authentication and authorization requirements.

Database Credentials

Choose this application type to connect directly to a database, which requires details like host, username and password, name, and port. OneTrust supports the following database types:

Simple Connect Credentials

Alternatively, to avoid supplying technical details from your system's console, you can choose the Simple Connect method. Limited currently to Azure AD, this credential type helps authorize faster by accessing the system tenant directly for this information. The requesting user must have the necessary authorization to access the tenant. Some systems, like Okta, are simple username/password requirements, while others will require approved organization access.

This is best used for first-time adoption. To leverage more secure credentials, OneTrust recommends the Custom option in order to provide these technical details.

Note:

For more details on using this credential option, see Azure AD Scan Assets Wizard.



SOAP API Credentials

You will need to create credentials for the system when configuring integration workflows with SOAP calls. These credentials can be any authentication methods which are supported by your system.

XML Envelope Options

You can send usernames and passwords in SOAP envelopes via Basic Authentication and any form of OAuth 2.0, which sends the token in the SOAP envelope rather than in the HTTPS headers. You will need to select XML Envelope in the Send Credentials In field during credential setup.

Note:

For more information, see Using SOAP APIs in OneTrust Integrations.