This page will explain how to provide authentication for Transposit's data connectors.
Given OAuth settings (i.e. client IDs and secrets), Transposit will automatically handle the OAuth 2.0 authentication flow to procure an access token and refresh as needed. For most data connections that require OAuth, Transposit provides these settings for limited use. For these data connections, no further setup is required for authorization after the connection is added.
If you do not want to use the Transposit-provided OAuth settings, you always have the option to overwrite the configuration with your own custom OAuth settings. A small subset of data connections will require you to provide custom OAuth settings because no feasible Transposit-provided OAuth settings exist for those connections.
To use your own client ID and secret:
https://accounts.transposit.com/oauth/v2/handle-redirectas a Redirect URI.
You can configure your own client ID and secret under Authentication > Configure or customize the scope (what permissions your users will be allowing with the connector when they authenticate with your app) under Configuration.
The following connectors require custom OAuth settings. When you add the connector to your service, you will be prompted to add these settings. Follow the links to create your own developer apps:
Below are links to create developer apps (to generate your own OAuth settings) if you do not want to use the Transposit-provided settings:
transposit.comas an authorized domain.
https://accounts.transposit.com/oauth/v2/handle-redirectas an authorized redirect URI. If you did not properly set up your authorized domain in your consent screen, you may get an
Invalid Redirecterror. If so, follow the link and add
transposit.comto the authorized domains list.
If you would like others to use your application, you may need to get it verified by Google.
The scope of a data connector defines what permissions your users will be allowing your app. By default, the range of scopes for each data connector is fairly permissive. You can add or remove scopes for your data connectiors as you see fit.
For data connections that implement authentication with header parameters, such as PagerDuty, the header parameter name (as documented by the external API site) and header parameter value (typically a secret token distributed by the external API site) must be provided when adding the connection to an application.
For data connections that implement authentication with query parameters, such as Zoom, only the query parameter value (typically a secret distributed by the external API site) must be provided when adding the connection to an application.
For AWS data connections, such as Lambda, the required combination of authentication parameters 'Access Key', 'Secret Key', and 'Role' depends on the authentication setup of your particular AWS service being connected to. The pair of 'Access Key' and 'Secret Key' authenticates you as an IAM user, and the 'Role' can be used to specify the ARN of an IAM role.
Example: Lambda with all three parameters provided (i.e. authentication as an IAM user assuming an IAM role)