Using OAuth Grant Types in OneTrust Integrations

The OAuth 2.0 authorization protocol provides additional grant types OneTrust users can leverage when creating custom system credentials to align with their integration needs or business requirements. For more information on integration credentials, see Configuring Integration Credentials.

Creating OAuth Credentials

  1. On the Integrations menu, select Credentials. The Credentials screen appears.

  2. Click the Add New button. The Select System screen appears.

  3. Enter your system in the Select System field, then click the Next button. The Enter Credential Details screen appears.

  4. You will need to specify the Connector Type as HTTP and the Auth Type as OAuth 2.

    Note:

    If these suggested fields aren't desired or useful to your given needs, select Custom as the Credential Type to configure a custom credential.

  5. Select your desired Grant Type from the available options. For additional context, see Supported Grant Types.

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

Supported Grant Types

This authentication method requires the provision of information shared between OneTrust and the given system that may warrant one of the following supported grant types:

Grant Type

Description

Password Credentials

This grant type requires a username and password to obtain an access token which is then used to authenticate.

Refresh Token

This grant type requires you generate a refresh token in the application with the provision of an access token URL. The token's expiration is dependent on the system that issues the token.

Client Credentials

An ideal option for connecting server-to-server applications, this grant type often requires the creation of OneTrust as an app/account in the system instance. You would then acquire and provide the following in order to create the credential in OneTrust:

  • Client ID

  • Client Secret

  • Scope

  • Access Token URL

Note:

For information about token reuse, retry behavior, and receiving-system logs, see OAuth 2.0 token reuse and retry behavior in Configuring Integration Credentials.

Signed Client Credentials

This grant type is similar to 'Client Credentials' except all token requests include a HMAC signature. Nonce and Timestamp will be calculated dynamically when requesting the token.

  • Consumer Key

  • Consumer Secret

  • Token Secret

  • Signature Method

    • HMAC-SHA1

    • HMAC-SHA256

  • Timestamp

  • Nonce

  • Version

  • Realm

Authorization Code

This grant type provides a temporary code which can be exchanged for an access token. It will require a more manual interaction on behalf of the user in order to authorize the initial request for an access token and refresh token, then return at a specified time to generate the token once again to prompt authorization.

This grant type also requires an Auth URL where OneTrust will direct the user to login to a system, upon which permits OneTrust to access on their behalf the items identified within the Scope field.

Important:

Refresh tokens issued by the OAuth 2.0 Authorization Code flow will expire and are not automatically renewed. Refresh tokens stored in OneTrust must be manually regenerated via the same Authorization Code flow prior to or upon expiration.

JSON Web Token (JWT)

This grant type allows the use of JSON signed web tokens (JWTs) flow to connect to systems, which requires a valid JWT token supplied in the first portion of OAuth 2.0 flow. This retrieves a bearer token that can be used to access resources.

Note:

For more information, see Generating JWT Credentials.

The following Registered Claim Names are supported for the JWT grant type:

  • Issuer Claim (iss)

  • Subject Claim (sub)

  • Audience Claim (aud)

  • Expiration Time Claim (exp)

  • Not Before Claim (nbf)

  • Issued At Claim (iat)

  • JWT ID Claim (jti)

  • Custom Claims

Note:

If additional headers are supplied, they will be appended to the standard JWT headers (this is not HTTP headers); however, if the standard "alg" or "typ" headers are provided in the additional section they should be ignored.