OAuth 2.0 grant type support

The following table shows the OAuth 2.0 grant types supported by Hybrid Data Pipeline by data store. Note that support for a grant type is limited to the grant types supported by the data store or data service to which you are connecting.

The grant type used to authorize access to a data store dictates the information you must provide when configuring a data source to use OAuth 2.0. This information may include endpoints, client information, and token information. This information is entered as parameters when you create a Hybrid Data Pipeline data source. The following sections provide guidance on the parameters that may be required for each grant type.

• Access token
• Authorization code
• Client credentials
• Refresh token

Access token

The access token flow may be implemented by entering OAuth parameters directly. In the access token flow, Hybrid Data Pipeline passes the access token directly to the data store. The following parameters may be required.

• Client ID may be required. It may be obtained through the client application registration process.
• Client Secret may be required. It may be obtained through the client application registration process.
• Access Token is required. It may be obtained using the authorization code grant either through the Hybrid Data Pipeline Web UI or through a third-party tool such as Postman.
• Scope may be required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.

Authorization code

The authorization code grant may be implemented either by entering OAuth parameters directly or by providing access with OAuth application and profile objects. With this grant type, Hybrid Data Pipeline exchanges an authorization code for an access token after the end user grants Hybrid Data Pipeline consent to access a data store. When implemented with the OAuth application and profile objects, the separation between the application verification process and the consent process is maintained. The following parameters may be required.

• Authorization URI is required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.
• Token URI is required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.
  Important: Depending on the data store the token URI may need to be prefixed with the REST method POST. For example, a Dynamics 365 app with the token URI:

  https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

  should be entered as:

  POST https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

• Client ID is required. It may be obtained through the client application registration process.
• Client Secret is required. It may be obtained through the client application registration process.
• Access Token is required. After entering the authorization URI, token URI, client ID, client secret, and scope, the access token may be obtained through the Hybrid Data Pipeline Web UI by pressing Fetch OAuth Token when creating a data source. Pressing Fetch OAuth Token initiates the authorization process.
• Refresh Token is required. After entering the authorization URI, token URI, client ID, client secret, and scope, the refresh token may be obtained through the Hybrid Data Pipeline Web UI by pressing Fetch OAuth Token when creating a data source. Pressing Fetch OAuth Token initiates the authorization process.
• Scope may be required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.

Client credentials

The client credentials grant may be implemented by entering OAuth parameters directly. The client credentials grant allows Hybrid Data Pipeline to exchange client credentials for access or refresh tokens. The following parameters may be required.

• Token URI is required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.
  Important: Depending on the data store the token URI may need to be prefixed with the REST method POST. For example, a Dynamics 365 app with the token URI:

  https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

  should be entered as:

  POST https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

• Client ID is required. It may be obtained through the client application registration process.
• Client Secret is required. It may be obtained through the client application registration process.
• Scope may be required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.

Refresh token

The refresh token flow may be implemented by entering OAuth parameters directly. In the refresh token flow, Hybrid Data Pipeline exchanges the refresh token for an access token. The following parameters may be required.

• Token URI may be required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.
  Important: Depending on the data store the token URI may need to be prefixed with the REST method POST. For example, a Dynamics 365 app with the token URI:

  https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

  should be entered as:

  POST https://login.microsofonline.com/adbd-efgh-1234-56789/oauth2/v2.0/token

• Client ID may be required. It may be obtained through the client application registration process.
• Client Secret may be required. It may be obtained through the client application registration process.
• Refresh Token is required. It may be obtained using the authorization code grant either through the Hybrid Data Pipeline Web UI or through a third-party tool such as Postman.
• Scope may be required. It should be available through the data store or data service user interface. It may be shown during the client application registration process.