Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The provider requests tables and views from Airtable. Authenticate, specify a base, and specify a list of tables to connect.
ApiKey: Log into Airtable and navigate to the Account icon in the top-right corner. Then, select Account from the dropdown menu. From the Account page, navigate to the API section. Then, click Generate API key. Set the ApiKey to the generated key.
BaseId: From the same API section, identify your BaseId. To locate this value, navigate to https://airtable.com/api and select a base. In the introduction section of the Airtable documentation for the selected base, note the value specified in "The ID of this base is Id."
TableNames: A comma-separated list of table names for the selected base in the format TableA,TableB..etc.. Supply the table names exactly as they are displayed in the Airtable UI.
ViewNames (optional): A comma-separated list of views in the format TableA.ViewA,TableA.ViewB,..etc. These are the same names of the views as found in the UI.
Note: Do not use the '.' character in column names. It is used for building column names based on paths and may risk breaking INSERT/UPDATE statements. If you already have column names that contain the '.' character, set PathDelimiter to a character that is not used in column names.
You can optionally set the following to refine the data returned from Asana.
WorkspaceId: Set this to the globally unique identifier (gid) associated with your Asana Workspace to only return projects from the specified Workspace. To get your Workspace Id, navigate to https://app.asana.com/api/1.0/workspaces while logged into Asana. This displays a JSON object containing your Workspace name and Id.
ProjectId: Set this to the globally unique identifier (gid) associated with your Asana Project to only return data mapped under the specified Project. Project Ids can be found in the URL of your project's Overview page. This will be the numbers directly after /0/.
Asana uses the OAuth authentication standard.
To obtain an OAuthClientId, OAuthClientSecret, and CallbackURL, you first need to create an app linked to your Asana account.
To create an app linked to your Asana account:
Log in to your Asana account.
Navigate to My profile Settings > Apps > Manage Developer Apps or https://app.asana.com/0/developer-console.
Under My apps, select New app. Specify the app name, then select Create app.
Once your app created, set Redirect URL to http://localhost:33333 (or a different available port of your choice), then select add.
Once you are done with creating a new app, it will be displayed on your screen. From there, you can click View Client ID to reveal your newly created app's OAuthClientId and OAuthClientSecret.AuthScheme must be set to OAuth in all user account flows.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId (custom applications only): Set this to the client Id assigned when you registered your app.
OAuthClientSecret (custom applications only): Set this to the client secret assigned when you registered your app.
CallbackURL (custom application only): Set this to the redirect URI defined when you registered your app. For example: https://localhost:3333
When you connect, the provider opens Asana's OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
The provider obtains an access token from Asana and uses it to request data.
The OAuth values are saved in the path specified in OAuthSettingsLocation, to be persisted across connections.
The provider refreshes the access token automatically when it expires.
There are two services available for connecting to Exchange. These are EWS (Exchange Web Services) and the Microsoft Graph. Exchange Web Services is available for both Exchange OnPremise and Online, but is no longer receiving updates. Microsoft recommends switching to using the Microsoft Graph for Exchange Online users. Both are available with our tool.
To switch between the two, use the Schema connection property to set either EWS or MSGraph. If you wish to use EWS with Exchange Online, set Schema to EWS and the Platform to Exchange_Online.
When using an OnPremise edition of Exchange, OnPremise Set User, Password, and AuthScheme; by default, the provider performs Basic authentication, but Windows (NTLM), Kerberos, and delegated authentication are also supported.
To authenticate to Exchange using Kerberos, set the following properties:
AuthScheme: Set this to NEGOTIATE
KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.
KerberosSPN: Set this to the service and host of the Exchange Kerberos Principal. This will be the value prior to the '@' symbol (for instance, ) of the (for instance, ).
You can use one of the following options to retrieve the required Kerberos ticket.
This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you won't need to set the User or Password connection properties with this option.
Ensure that you have an environment variable created called KRB5CCNAME.
Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file will be created when generating your ticket with MIT Kerberos Ticket Manager.
To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.
Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Exchange.
As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider will use the specified cache file to obtain the kerberos ticket to connect to Exchange.
If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.
If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a User and Password combination. To do this, set the User and Password properties to the user/password combo that you use to authenticate with Exchange.
More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g. where one realm/KDC is used for user authentication and another realm/KDC used for obtaining the service ticket).
In such an environment, the KerberosRealm and KerberosKDC properties can be set to the values required for user authentication. The KerberosServiceRealm and KerberosServiceKDC properties can be set to the values required to obtain the service ticket.
In addition to the authentication values, set the Server property to the address of the Exchange server you are connecting to and set Platform to the Exchange version. Finally, set Schema to EWS.
When connecting to Exchange Online, authentication will be done via OAuth. If you are connecting to Exchange Online platform through EWS, set the AuthScheme property to OAuth. Otherwise if you will be using Microsoft Graph to connect to Exchange Online, resources will be pulled from a different service so the Schema should be set to MSGraph. When Schema is set to MSGraph, the Platform value will be ignored.
Follow the steps below to obtain the OAuth values for your app, the OAuthClientId and OAuthClientSecret.
Log in to https://portal.azure.com.
In the left-hand navigation pane, select Azure Active Directory then App Registrations and click the Add button.
Enter an app name and set the radio button for "Any Azure AD Directory - Multi Tenant". Then set the redirect url to something such as http://localhost:33333, the provider's default. Or, set a different port of your choice and set CallbackURL to the exact reply URL you defined.
After creating the app, go to the Certificates & Secrets section, create a Client Secret for the app and select a duration.
After you save the key, a value for the key is displayed once. Set OAuthClientSecret to the key value. Set OAuthClientId to the Application Id.
Select API Permissions and then click Add. If you plan for your app to connect without a user context, select the Application Permissions (OAuthGrantType = CLIENT). Otherwise, when selecting permissions, use the Delegated permissions.
If you are connecting to Exchange through EWS schema, select Exchange API and add EWS.AccessAsUser.All permission. If you are connecting to Exchange through MSGraph schema, select Microsoft Graph API and add the following permissions: Calendars.ReadWrite.Shared, Contacts.ReadWrite, Group.Read.All, Group.ReadWrite.All, User.ReadWrite.All, and Mail.ReadWrite.Shared.
Save your changes.
If you have selected to use permissions that require admin consent (such as the Application Permissions), you may grant them from the current tenant on the API Permissions page. Otherwise, follow the Admin consent steps below
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
When creating a new OAuth app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked stating "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, there will be a button for Grant Consent. You can consent here for your app to have permissions on the tenant it was created under.
OAuth requires the authenticating user to interact with Dropbox using the browser. The provider facilitates this in various ways as described below.
Log in to your Dropbox developers dashboard and click Create New App. Select the Dropbox API type. Select the Full Dropbox access for your app.
After creating your app, you can view Configuration from the main menu that displays your app settings.
Set the Redirect URI to http://localhost:33333 or a different port number of your choice. When you connect you will need to set the CallbackURL connection property to this exact URL.
The OAuthClientId and OAuthClientSecret are also displayed in the same page.
There are some views (DeletedResources, Events, Teams, TeamMembers) and stored procedures (DeletePermanently) that require certain scopes that are not present in the default connection. To access these, you will need to create your own custom app and grant the following permissions:
team_info.read
files.permanent_delete
members.read
groups.read
team_data.member
events.read
The following are the connection properties for Dropbox. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.
Use the OAuth authentication standard to connect to Box. You can authenticate with a user account or with a service account. A service account is required to grant organization-wide access scopes to the provider. The provider facilitates these authentication flows as described below.
Note: Set the AuthScheme to OAuth to authenticate with this method.
Log in to your Box developers dashboard and click Create New App. Select your app type (e.g., Custom App).
Select the Standard OAuth 2.0 (User Authentication) authentication method and click View Your App. (After creating your app, you can click Configuration from the main menu to access your app settings.)
Set the Redirect URI to http://localhost:33333 or a different port number of your choice. When you connect you will need to set the CallbackURL connection property to this exact URL.
The OAuthClientId and OAuthClientSecret are also displayed in the same page.
Select the scope of user permissions your app will request.
Note: Set the AuthScheme to OAuthJWT to authenticate with this method.
Service accounts have silent authentication, without user authentication in the browser. You can also use a service account to delegate enterprise-wide access scopes to the provider.
Follow the steps below to create an OAuth application and generate a private key. You will then authorize the service account.
Log in to your Box developers dashboard and click Create New App. Select your app type (e.g., Custom App).
Select the OAuth 2.0 with JWT (Server Authentication) authentication method and click View Your App. (After creating your app, you can click Configuration from the main menu to access your app settings.)
Select the application access level and the scope of user permissions your app will request. The enterprise access level enables you to work with existing users in your enterprise. The application-level setting restricts access to App-type users, users that have only API access.
Generate your RSA keypair. First you need to generate your private key. You can do this by running the following OpenSSL command : "openssl genrsa -aes128 -out private_key.pem 2048" (you can install and use the Cygwin package to run the OpenSSL RSA keypair if you are using Windows).
Generate your public key by running the following OpenSSL command: "openssl rsa -pubout -in private_key.pem -out public_key.pem". Copy the contents of the generated public_key.pem file and then add it by using the Add and Manage Public Keys option in your app settings.
6. Authorize the application in the enterprise admin console: Click Apps -> Custom Applications -> Authorize New App and enter the Client Id in your app settings.
Note: If you change the JWT access scopes, you will need to reauthorize the application in the enterprise admin console: Click Apps in the main menu and then select the ellipsis button next to your JWT application name. Select Reauthorize App in the menu.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set to GETANDREFRESH.
OAuthClientId: Set to the Client Id in your app settings.
OAuthClientSecret: Set to the Client Secret in your app settings.
OAuthJWTCertType: Set to "PEMKEY_FILE".
OAuthJWTCert: Set to the path to the .pem file you generated.
OAuthJWTCertPassword: Set to the password of the .pem file.
OAuthJWTCertSubject: Set to "*" to pick the first certificate in the certificate store.
OAuthJWTSubjectType: Set to "enterprise" or "user" depending on the Application Access Value you selected in your app settings. The default value of this connection property is "enterprise".
OAuthJWTSubject: Set to your enterprise Id if your subject type is set to "enterprise" or your app user Id if your subject type is set to "user".
OAuthJWTPublicKeyId: Set to the Id of your public key in your app settings.
When you connect the provider completes the OAuth flow for a service account.
Creates and signs the JWT with the claim set required by the provider.
Exchanges the JWT for the access token.
Saves OAuth values in OAuthSettingsLocation to be persisted across connections.
Submits the JWT for a new access token when the token expires.
The following are the connection properties for Box. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.
Property
Description
Caching
CacheTolerance
The tolerance for stale data in the cache specified in seconds when using AutoCache .
Firewall
FirewallPassword
A password used to authenticate to a proxy-based firewall.
FirewallPort
The TCP port for a proxy-based firewall.
FirewallServer
The name or IP address of a proxy-based firewall.
FirewallType
The protocol used by a proxy-based firewall.
FirewallUser
The user name to use to authenticate with a proxy-based firewall.
Logging
Logfile
A file path which designates the name and location of the log file.
LogModules
Core modules to be included in the log file.
MaxLogFileCount
A string specifying the maximum file count of log files. When the limit is hit, a new log is created in the same folder with the date and time appended to the end and the oldest log file will be deleted.
MaxLogFileSize
A string specifying the maximum size in bytes for a log file (for example, 10 MB). When the limit is hit, a new log is created in the same folder with the date and time appended to the end.
Verbosity
The verbosity level that determines the amount of detail included in the log file.
Misc
ConnectionLifeTime
The maximum lifetime of a connection in seconds. Once the time has elapsed, the connection object is disposed.
ConnectionString
***
ImpersonateUserId
Specify the User Id to impersonate.
ImpersonateUserMode
Specify the type of the user impersonation. It should be whether the User mode or the Admin mode.
IncludeSubDirectories
Indicates if you want to include sub directories while listing files and folders.
IncludeTeamResources
Indicates if you want to include team files and folders.
MaxRows
Limits the number of rows returned rows when no aggregation or group by is used in the query. This helps avoid performance issues at design time.
Other
These hidden properties are used only in specific use cases.
PoolIdleTimeout
The allowed idle time for a connection before it is closed.
PoolMaxSize
The maximum connections in the pool.
PoolMinSize
The minimum number of connections in the pool.
PoolWaitTime
The max seconds to wait for an available connection.
PseudoColumns
This property indicates whether or not to include pseudo columns as columns to the table.
SSLServerCert
The certificate to be accepted from the server when connecting using TLS/SSL.
SupportEnhancedSQL
This property enhances SQL functionality beyond what can be supported through the API directly, by enabling in-memory client-side processing.
Timeout
The value in seconds until the timeout error is thrown, canceling the operation.
UseConnectionPooling
This property enables connection pooling.
OAuth
CallbackURL
The OAuth callback URL to return to when authenticating. This value must match the callback URL you specify in your app settings.
InitiateOAuth
Set this property to initiate the process to obtain or refresh the OAuth access token when you connect.
OAuthAccessToken
The access token for connecting using OAuth.
OAuthClientId
The client ID assigned when you register your application with an OAuth authorization server.
OAuthClientSecret
The client secret assigned when you register your application with an OAuth authorization server.
OAuthExpiresIn
The lifetime in seconds of the OAuth AccessToken.
OAuthRefreshToken
The OAuth refresh token for the corresponding OAuth access token.
OAuthSettingsLocation
The location of the settings file where OAuth values are saved when InitiateOAuth is set to GETANDREFRESH or REFRESH. Alternatively, this can be held in memory by specifying a value starting with memory://.
OAuthTokenTimestamp
The Unix epoch timestamp in milliseconds when the current Access Token was created.
OAuthVerifier
The verifier code returned from the OAuth authorization URL.
Proxy
ProxyAuthScheme
The authentication type to use to authenticate to the ProxyServer proxy.
ProxyAutoDetect
This indicates whether to use the system proxy settings or not. This takes precedence over other proxy settings, so you'll need to set ProxyAutoDetect to FALSE in order use custom proxy settings.
ProxyExceptions
A semicolon separated list of destination hostnames or IPs that are exempt from connecting through the ProxyServer .
ProxyPassword
A password to be used to authenticate to the ProxyServer proxy.
ProxyPort
The TCP port the ProxyServer proxy is running on.
ProxyServer
The hostname or IP address of a proxy to route HTTP traffic through.
ProxySSLType
The SSL type to use when connecting to the ProxyServer proxy.
ProxyUser
A user name to be used to authenticate to the ProxyServer proxy.
Property
Description
Authentication
AuthScheme
The type of authentication to use when connecting to Box.
ImpersonateUserMode
Specify the type of the user impersonation. It should be whether the User mode or the Admin mode.
OAuthJWTPublicKeyId
The Id of the public key for JWT.
OAuthJWTSubjectType
The SubType for the JWT authentication.
Caching
CacheTolerance
The tolerance for stale data in the cache specified in seconds when using AutoCache .
Firewall
FirewallPassword
A password used to authenticate to a proxy-based firewall.
FirewallPort
The TCP port for a proxy-based firewall.
FirewallServer
The name or IP address of a proxy-based firewall.
FirewallType
The protocol used by a proxy-based firewall.
FirewallUser
The user name to use to authenticate with a proxy-based firewall.
JWTOAuth
OAuthJWTCert
The JWT Certificate store.
OAuthJWTCertPassword
The password for the OAuth JWT certificate.
OAuthJWTCertSubject
The subject of the OAuth JWT certificate.
OAuthJWTCertType
The type of key store containing the JWT Certificate.
OAuthJWTIssuer
The issuer of the Java Web Token.
OAuthJWTSubject
The user subject for which the application is requesting delegated access.
Logging
Logfile
A filepath which designates the name and location of the log file.
LogModules
Core modules to be included in the log file.
MaxLogFileCount
A string specifying the maximum file count of log files. When the limit is hit, a new log is created in the same folder with the date and time appended to the end and the oldest log file will be deleted.
MaxLogFileSize
A string specifying the maximum size in bytes for a log file (for example, 10 MB). When the limit is hit, a new log is created in the same folder with the date and time appended to the end.
Verbosity
The verbosity level that determines the amount of detail included in the log file.
Misc
ConnectionLifeTime
The maximum lifetime of a connection in seconds. Once the time has elapsed, the connection object is disposed.
ConnectionString
***
DirectoryRetrievalDepth
Depth level of folder to query Folders and Files tables.
IncludeCustomFields
Set to true if metadata templates should be exposed as custom columns of the table Files.
MaxRows
Limits the number of rows returned rows when no aggregation or group by is used in the query. This helps avoid performance issues at design time.
Other
These hidden properties are used only in specific use cases.
PoolIdleTimeout
The allowed idle time for a connection before it is closed.
PoolMaxSize
The maximum connections in the pool.
PoolMinSize
The minimum number of connections in the pool.
PoolWaitTime
The max seconds to wait for an available connection.
PseudoColumns
This property indicates whether or not to include pseudo columns as columns to the table.
Readonly
You can use this property to enforce read-only access to Box from the provider.
SSLServerCert
The certificate to be accepted from the server when connecting using TLS/SSL.
SupportEnhancedSQL
This property enhances SQL functionality beyond what can be supported through the API directly, by enabling in-memory client-side processing.
Timeout
The value in seconds until the timeout error is thrown, canceling the operation.
UseConnectionPooling
This property enables connection pooling.
OAuth
CallbackURL
The OAuth callback URL to return to when authenticating. This value must match the callback URL you specify in your app settings.
InitiateOAuth
Set this property to initiate the process to obtain or refresh the OAuth access token when you connect.
OAuthAccessToken
The access token for connecting using OAuth.
OAuthClientId
The client ID assigned when you register your application with an OAuth authorization server.
OAuthClientSecret
The client secret assigned when you register your application with an OAuth authorization server.
OAuthExpiresIn
The lifetime in seconds of the OAuth AccessToken.
OAuthRefreshToken
The OAuth refresh token for the corresponding OAuth access token.
OAuthSettingsLocation
The location of the settings file where OAuth values are saved when InitiateOAuth is set to GETANDREFRESH or REFRESH. Alternatively, this can be held in memory by specifying a value starting with memory://.
OAuthTokenTimestamp
The Unix epoch timestamp in milliseconds when the current Access Token was created.
OAuthVerifier
The verifier code returned from the OAuth authorization URL.
Proxy
ProxyAuthScheme
The authentication type to use to authenticate to the ProxyServer proxy.
ProxyAutoDetect
This indicates whether to use the system proxy settings or not. This takes precedence over other proxy settings, so you'll need to set ProxyAutoDetect to FALSE in order use custom proxy settings.
ProxyExceptions
A semicolon separated list of destination hostnames or IPs that are exempt from connecting through the ProxyServer .
ProxyPassword
A password to be used to authenticate to the ProxyServer proxy.
ProxyPort
The TCP port the ProxyServer proxy is running on.
ProxyServer
The hostname or IP address of a proxy to route HTTP traffic through.
ProxySSLType
The SSL type to use when connecting to the ProxyServer proxy.
ProxyUser
A user name to be used to authenticate to the ProxyServer proxy.
Office 365 uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
If you are running Office 365 on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials will then be automatically obtained for authentication.
Microsoft OneDrive uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
Azure AD is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with Microsoft Teams using an internet browser. The provider facilitates this in several ways as described below. Set your AuthScheme to AzureAD. All AzureAD flows assume that you have done so.
See Creating a Custom AzureAD App for information about creating custom applications and reasons for doing so.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Admin Consent
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
Admin Consent Permissions
When creating a new AzureAD app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked as "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, click Grant Consent for your app to have permissions on the tenant under which it was created.
After the administrator has approved the OAuth Application, you can continue to authenticate.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
Client OAuth Flow
All permissions related to the client oauth flow require admin consent. You must create your own OAuth app in order to use client credentials. See Creating a Custom AzureAD App for more details.
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the permissions you require for your integration.
You are ready to connect after setting one of the connection properties groups depending on the authentication type.
Authenticating using a Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials takes place automatically like any other connection, except there is no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
Note: You must create a custom application prior to assigning a role. See Creating a Custom AzureAD App for more information.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Microsoft Teams on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
The provider supports using user accounts, service accounts and GCP instance accounts for authentication.
The following sections discuss the available authentication schemes for Google Drive:
User Accounts (OAuth)
Service Account (OAuthJWT)
GCP Instance Account
AuthScheme must be set to OAuth in all user account flows.
Follow these steps to enable the Google Drive API:
Navigate to the Google Cloud Console.
Select Library from the left-hand navigation menu. This opens the Library page.
In the search field, enter "Google Drive API" and select Google Drive API from the search results.
On the Google Drive API page, click ENABLE.
When using AuthScheme=OAuth, and you're using a web application, you must create an OAuth Client ID Application. For desktop and headless flows, creating a custom OAuth application is optional.
Follow these steps to create a custom OAuth application:
Navigate to the Google Cloud Console.
If you have not done so, follow the steps in the console to create an OAuth consent screen.
Select Credentials from the left-hand navigation menu.
On the Credentials page, select Create Credentials > OAuth Client ID.
In the Application Type menu, select Web application.
Specify a name for your OAuth custom web application.
Under Authorized redirect URIs, click ADD URI and enter a redirect URI. Press Enter.
Click CREATE, which returns you to the Credentials page.
A window opens that displays your client Id and client secret. Although the client secret is accessible from from the Google Cloud Console, we recommend you write down the client secret. You need both the client secret and client Id to specify the OAuthClientId and OAuthClientSecret connection properties.
To authenticate using a service account, you must create a new service account and have a copy of the accounts certificate.
When using AuthScheme=OAuthJWT, you must create a Service Account Application. Follow these steps:
Navigate to the Google Cloud Console.
If you have not done so, follow the steps in the console to create an OAuth consent screen.
Select Credentials from the left-hand navigation menu.
On the Credentials page, select Create Credentials > Service account.
On the Create service account page, enter the Service account name, the Service account ID, and, optionally, a description.
Click DONE. This returns you to the Credentials page.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH, which instructs the provider to automatically attempt to get and refresh the OAuth access token.
OAuthClientId: (custom applications only) Set this to the Client Id in your custom OAuth application settings.
OAuthClientSecret: (custom applications only) Set this to the Client Secret in the custom OAuth application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process as follows:
Extracts the access token from the callback URL.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
For a JSON file, set these properties:
AuthScheme: Set this to OAuthJWT.
InitiateOAuth: Set this to GETANDREFRESH.
OAuthJWTCertType: Set this to GOOGLEJSON.
OAuthJWTCert: Set this to the path to the .json file provided by Google.
OAuthJWTSubject: (optional) Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.
For a PFX file, set these properties instead:
AuthScheme: Set this to OAuthJWT.
InitiateOAuth: Set this to GETANDREFRESH.
OAuthJWTCertType: Set this to PFXFILE.
OAuthJWTCert: Set this to the path to the .pfx file provided by Google.
OAuthJWTCertPassword: (optional) Set this to the .pfx file password. In most cases you must provide this since Google encrypts PFX certificates.
OAuthJWTCertSubject: (optional) Set this only if you are using a OAuthJWTCertType which stores multiple certificates. Should not be set for PFX certificates generated by Google.
OAuthJWTIssuer: Set this to the email address of the service account. This address will usually include the domain iam.gserviceaccount.com.
OAuthJWTSubject: (optional) Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.
When running on a GCP virtual machine, the provider can authenticate using a service account tied to the virtual machine. To use this mode, set AuthScheme to GCPInstanceAccount.
alesforce Chatter uses OAuth 2.0 authentication. To authenticate to Salesforce Chatter via OAuth 2.0, you will need to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL by registering an app with Salesforce Chatter.
You can follow the procedure below to register an app and obtain the OAuth client credentials, the OAuthClientId and OAuthClientSecret:
Log into Salesforce.com.
From Setup, enter Apps in the Quick Find box and then click the link to create an app. In the Connected Apps section of the resulting page, click New.
Enter a name to be displayed to users when they log in to grant permissions to your app, along with a contact email address.
Click Enable OAuth Settings and enter a value in the Callback URL box.
If you are making a desktop application, set the Callback URL to https://localhost:33333 or a different port number of your choice.
If you are making a Web application, set the Callback URL to a page on your Web app you would like the user to be returned to after they have authorized your application. Note that you must redirect the user to an HTTPS URL.
Select the scope of permissions that your app will request from the user, including Chatter.
Once you have created the app, click your app name to open a page with information about your app. The OAuth client credentials, the consumer key and consumer secret, are displayed.
After setting the following connection properties, you are ready to connect:
OAuthClientId: Set this to the Consumer Key in your app settings.
OAuthClientSecret: Set this to the Consumer Secret in your app settings.
CallbackURL: Set this to the Callback URL in your app settings, https://localhost:portNumber.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken connection property.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Refreshes the access token when it expires.
Saves OAuth values in OAuthSettingsLocation to be persisted across connections.
Microsoft Teams uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
Azure AD is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with Microsoft Teams using an internet browser. The provider facilitates this in several ways as described below. Set your AuthScheme to AzureAD. All AzureAD flows assume that you have done so.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Admin Consent
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
Admin Consent Permissions
When creating a new AzureAD app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked as "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, click Grant Consent for your app to have permissions on the tenant under which it was created.
After the administrator has approved the OAuth Application, you can continue to authenticate.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
Client OAuth Flow
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the permissions you require for your integration.
You are ready to connect after setting one of the connection properties groups depending on the authentication type.
Authenticating using a Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials takes place automatically like any other connection, except there is no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Microsoft Teams on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
Microsoft OneNote uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
Azure AD is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with Microsoft Teams using an internet browser. The provider facilitates this in several ways as described below. Set your AuthScheme to AzureAD. All AzureAD flows assume that you have done so.
After setting the following connection properties, you are ready to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
OAuthClientId: (custom applications only) Set this to the client Id in your application settings.
OAuthClientSecret: (custom applications only) Set this to the client secret in your application settings.
CallbackURL: Set this to the Redirect URL in your application settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Obtains a new access token when the old one expires.
Saves OAuth values in OAuthSettingsLocation that persist across connections.
Admin Consent
Admin consent refers to when the Admin for an Azure Active Directory tenant grants permissions to an application which requires an admin to consent to the use case.
Admin Consent Permissions
When creating a new AzureAD app in the Azure Portal, you must specify which permissions the app will require. Some permissions may be marked as "Admin Consent Required". For example, all Groups permissions require Admin Consent. If your app requires admin consent, there are a couple of ways this can be done.
The easiest way to grant admin consent is to just have an admin log into portal.azure.com and navigate to the app you have created in App Registrations. Under API Permissions, click Grant Consent for your app to have permissions on the tenant under which it was created.
After the administrator has approved the OAuth Application, you can continue to authenticate.
Client Credentials
Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.
Client OAuth Flow
In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the permissions you require for your integration.
You are ready to connect after setting one of the connection properties groups depending on the authentication type.
Authenticating using a Client Secret
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthGrantType: Set this to CLIENT.
OAuthClientId: Set this to the client Id in your app settings.
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
Authentication with client credentials takes place automatically like any other connection, except there is no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.
Azure Service Principal is a connection type that goes through OAuth. Set your AuthScheme to AzureServicePrincipal. The authentication as an Azure Service Principal is handled via the OAuth Client Credentials flow, and it does not involve direct user authentication. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context, but based on the assigned roles. The application access to the resources is controlled through the assigned roles' permissions.
When authenticating using an Azure Service Principal, you must register an application with an Azure AD tenant. Follow the steps below to create a new service principal that can be used with the role-based access control.
Assign a role to the application
To access resources in your subscription, you must assign a role to the application.
Open the Subscriptions page by searching and selecting the Subscriptions service from the search bar.
Select the particular subscription to assign the application to.
Open the Access control (IAM) and select Add > Add role assignment to open the Add role assignment page.
Select Owner as the role to assign to your created Azure AD app.
Complete the Authentication
You are ready to connect after setting one of the below connection properties groups, depending on the configured app authentication (client secret or certificate).
In both methods
Before choosing client secret or certicate authentication, follow these steps then continue to the relevant section below:
AuthScheme: Set this to the AzureServicePrincipal in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
AzureTenant: Set this to the tenant you wish to connect to.
OAuthClientId: Set this to the client Id in your app settings.
Authenticating using a Client Secret
Continue with the following:
OAuthClientId: Set this to the client Id in your app settings.
OAuthClientSecret: Set this to the client secret in your app settings.
Authenticating using a Certificate
Continue with the following:
OAuthJWTCert: Set this to the JWT Certificate store.
OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.
If you are running Microsoft Teams on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:
AuthScheme: Set this to AzureMSI.
The MSI credentials are automatically obtained for authentication.
See for information about creating custom applications and reasons for doing so.
All permissions related to the client oauth flow require admin consent. You must create your own OAuth app in order to use client credentials. See for more details.
Note: You must create a custom application prior to assigning a role. See for more information.
See for information about creating custom applications and reasons for doing so.
All permissions related to the client oauth flow require admin consent. You must create your own OAuth app in order to use client credentials. See for more details.
Note: You must create a custom application prior to assigning a role. See for more information.
See
Slack uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
Create an app to obtain the OAuth client credentials, the OAuthClientId and OAuthClientSecret. To create your app, go to https://api.slack.com/apps. Specify an app name and the app's workspace. You can see the Client Id and Client Secret listed in the App Credentials section under Basic information.
After creating your application, define your app's CallbackURL:
In your app settings, go to OAuth & Permissions
In the Redirect URLs section click Add a New Redirect URL.
Set the callback URL to http://127.0.0.1:33333, or another port of your choice. Ensure that you save the URL.
Follow the instructions below to configure the API permissions your app requests. In order to use all possible features, the necessary scopes are: channels:read, groups:read, im:read, mpim:read, channels:write, groups:write, im:write, mpim:write, channels:history, groups:history, im:history, mpim:history, search:read, chat:write:user, chat:write:bot, files:read, files:write:user, pins:read, pins:write, usergroups:read, usergroups:write, reminders:read, reminders:write, users:read, users.profile:write.
In your app settings, go to the Scopes section, under OAuth & Permissions.
In the Select Permission Scopes subsection, click the menu to add permissions by scope or API method.
To allow users in other workspaces to install your app, follow the instructions below:
In your app settings, click Manage Distribution under the Settings section.
Complete the procedures to set a callback URL and configure permissions.
Click Activate Public Distribution.
Set the following connection properties to connect:
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the access token in the connection string.
OAuthClientId: Set this to the Client Id in your app settings.
OAuthClientSecret: Set this to the Client Secret in your app settings.
CallbackURL: Set this to the Redirect URL in your app settings.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Refreshes the access token when it expires.
Saves OAuth values in OAuthSettingsLocation to be persisted across connections.
Smartsheet supports connections via the following authentication methods:
Using the Personal Access Token
Using OAuth
Use the personal token to test and to access your own data. To obtain the personal token, follow the steps below:
Log into Smartsheet.
Click Account and select Personal Settings.
Click API Access and use the form to generate new access tokens or manage existing access tokens.
Set the AuthScheme to PersonalAccessToken. You can then set the PersonalAccessToken to the token you generated.
Smartsheet uses the OAuth authentication standard. To use it, you'll need to set the AuthScheme to OAuth. To authenticate using OAuth, you will need to register an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
However, to access your own account or for testing purposes you can instead set the PersonalAccessToken connection property to the Personal Access Token you get when you create an application.
For this step you need a developer account. You can follow the procedure below to register an app and obtain the OAuth client credentials, the client Id and client secret:
Log into your Smartsheet developer account and click Account -> Developer Tools -> Create New App.
Enter a name, description, and other information to be displayed to users when they log in to grant permissions to your app.
If you are making a desktop application, set the Redirect URL to http://localhost:33333 or a different port number of your choice.
If you are making a Web application, set the Redirect URL to a page on your Web app you would like the user to be returned to after they have authorized your application.
After setting the following connection properties, you are ready to connect:
OAuthClientId: Set this to the App client id in your app settings.
OAuthClientSecret: Set this to the App secret in your app settings.
CallbackURL: Set this to the App redirect URL in your app settings.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken connection property.
When you connect the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:
Extracts the access token from the callback URL and authenticates requests.
Refreshes the access token when it expires.
Saves OAuth values in OAuthSettingsLocation to be persisted across connections.