Find us at our new Help Center where we've combined our documentation and knowledgebase articles in one easy-to-search location.
We aren't updating the Developer Portal anymore, except for the Element Docs — all updates happen in the Help Center. We're retiring the Developer Portal as you know it in:
The information that you need to enter to set up authentication with the API provider differs depending on the authentication type. If the API provider requires complex authentication you can override the default information with configurations, parameters , and hooks.
Click the authentication type that you selected to see configuration instructions. If you selected Custom, you can skip directly to Configuration and Parameters.
Cloud Elements provides the properties needed to support a standard OAuth 2.0 flow. Each API provider implements OAuth 2.0 differently so you might need to supplement the parameters with additional configuration. Before setting up the OAuth 2.0 information, you need to create a Cloud Elements app at the API provider. Use the default information from that app. When users authenticate through Cloud Elements, they will connect with that app.
The OAuth 2.0 entry in the About OAuth Authentication section includes more details about the most common OAuth 2.0 authentication flow.
To configure OAuth 2.0 elements:
Name | Key | Description | Required |
---|---|---|---|
OAuth API Key | oauth.api.key | The default API Key used to authenticate with the API provider. Most API providers call this some variation of key or id, such as Key, API Key, or Client ID. | Y |
OAuth API Secret | oauth.api.secret | The default API Secret used to authenticate with the API provider. Most API providers call this some variation of secret, such as Secret , API Secret, or Client Secret. | Y |
OAuth Callback URL | oauth.callback.url | The URL that will receive the authorization code from the API provider used to authenticate an element instance. For authentication through Cloud Elements, use https://auth.cloudelements.io/oauth . |
Y |
OAuth Authorization URL | oauth.authorization.url | The URL where a user authorizes the application to access their information at the API provider. | Y |
OAuth Token URL | oauth.token.url | The URL where the application exchanges the authorization grant code or request token for an access token. | Y |
OAuth Scope | oauth.scope | A comma separated list of the permissions that the user will authorize your integration to have. | N |
OAuth Refresh Interval (s) | oauth.user.refresh_interval | If the access token expires, the time frame in seconds when Cloud Elements sends a request to the OAuth Token Refresh URL. The default is 3600, which is one hour. | N |
OAuth Token Refresh URL | oauth.token.refresh_url | The URL to send a refresh request. | N |
OAuth Revoke Token URL | oauth.token.revoke_url | The URL to send requests to revoke refresh or access tokens. | N |
Cloud Elements provides the parameters required to support a standard OAuth 1.0 flow. Each API provider implements OAuth 1.0 differently so you might need to supplement the parameters with additional configuration.
The OAuth 1.0 entry in the About Authentication section includes more details about the most common OAuth 2.0 authentication flow.
To configure OAuth 1.0 elements:
Name | Key | Description | Required |
---|---|---|---|
OAuth Request URL | oauth.request.url | The URL used to get an unauthorized request token. | Y |
OAuth Callback URL | oauth.callback.url | The URL that will receive the authorization code from the API provider used to authenticate an element instance. | Y |
OAuth API Key | oauth.api.key | The default API Key used to authenticate with the API provider. Most API providers call this some variation of key or id, such as Key, API Key, or Client ID. | Y |
OAuth API Secret | oauth.api.secret | The default API Secret used to authenticate with the API provider. Most API providers call this some variation of secret, such as Secret , API Secret, or Client Secret. | Y |
OAuth Authorization URL | oauth.authorization.url | The URL where a user authorizes the application to access their information at the API provider. | Y |
OAuth Token URL | oauth.token.url | The URL where the application exchanges the authorization grant code or request token for an access token. | Y |
OAuth Authorization Type (Header or Query) | oauth.request.authorization.type | How the API provider receives authentication information, either in the header or as a query parameter. | Y |
OAuth Scope | oauth.scope | A comma separated list of the permissions that the user will authorize your integration to have. | N |
OAuth User Secret | oauth.user.token.secret | The user secret associated with the application authenticating with the API provider. | N |
In Basic access authentication, you typically provide a user name and password. In some cases you also provide an API Key. When setting up an element with Basic authentication we start you off with Username (key:username
) and Password(key:password
) configurations. If you need to add any other configurations like an API Key, do so in the Configuration step. API providers typically do not vary from the standard Basic authentication, so you should keep the default properties. If you do need to make changes, you can update the properties or delete unneeded configurations.
Parameter | Description | Required |
---|---|---|
Name | The visible name of the configuration as it appears in the Cloud Elements UI. | Y |
Key | The internal unique identifier for the configuration. The configuration key value appears in the authentication JSON. You also refer to the configuration by configuration key in parameters and hooks. | Y |
Type | The type of configuration, which can be any of the following: | Y |
Text Area, Text Text 32, Text 64, Text 100, Text 128 — Identifies configurations that accept free text strings. | ||
true/false and yes/no — Identifies configurations that accept boolean inputs. | ||
password — Identifies configurations intended to collect passwords. Passwords are masked in Cloud Elements. | ||
Required | Identifies whether the configuration is required. Switch on to force a user to provide data when authenticating. Configurations not required, but that show in Cloud Elements appear under Show Optional Fields. | Y |
Hide on UI | Identifies whether the configuration appears in Cloud Elements. Switch on to show the configuration in Cloud Elements. The configuration appears to the user with the configuration name and the description as hover help text. | Y |
Configuration Description | The description appears as hover help text. The text space available is limited, so write brief but useful descriptions. | Y |
Default Value | The default value of the configuration. | N |
To configure custom authentication information, use the Configuration, Parameters, and, if necessary, Hooks sections to construct the authentication information required by the API provider.
Cloud Elements provides default authentication fields for API providers that use Amazon Web Services Signature Version 4 and Version 2. API providers typically do not vary from the standard AWS authentications, so you should keep the default properties. If you do need to make changes, you can update the properties or delete unneeded configurations.
Name | Description | Required |
---|---|---|
AWS Access Key ID | The ID associated with your AWS access key. | Y |
AWS Secret Access Key | The secret key used in the Signature Version 2 signing process | Yes for version 2 only |
AWS Region Name, e.g., us-west-2 | The Amazon API Gateway region name. | Yes for version 4 only |
If you selected the incorrect authentication type, or find that you need to change the authentication, select another authentication type from the type list in the Authentication heading.
Continue to the next step, Custom Configuration and Parameters.
After you set up authentication you can authenticate an element instance to see if you can create a connection. If you chose Custom authentication or need to add additional configurations and parameters, you should set those up before testing authentication.
To test your authentication:
If the authentication succeeds, Cloud Elements creates an authenticated instance which you can use to test your authentication. You can also use it later when you test resources.
OAuth is a common authentication protocol for REST APIs and Cloud Elements supports both OAuth 2.0 and OAuth 1.0. You need to set up more information for OAuth elements than other authentication types. This section provides more details about how these authentication types work and how Cloud Elements uses the information you provide when building custom elements.
The OAuth 2.0 protocol lets external applications — your application or Cloud Elements — request authorization to access and update a users data without asking users for sensitive user names and passwords. OAuth 2.0 is flexible, but that also means that each API provider implements it differently.
This section describes how Cloud Elements supports the Authorization Code Grant workflow authentication flow. Other flows such as Implicit Grant and Client Credentials Grant offer variations that we also support. The Authorization Code Grant flow is sometimes called a three-legged authentication process:
The typical Authorization Code Grant flow as supported by Cloud Elements includes the following steps:
The API provider redirects the user back to the OAuth Callback URL with the following parameters:
code
.A state
parameter that is typically the element key.
error
instead of the code
parameter. Cloud Elements makes a backchannel request to redeem the authorization grant code for an access token.
The API provider authenticates the element instance and issues an access token. Some API providers also provide a refresh token and information about when the token expires.
Cloud Elements associates an element instance token with the access token. You will use that element instance token in future requests.
If the tokens expire, Cloud Elements sends the refresh token to the OAuth Token Refresh URL at the specified OAuth Refresh Interval (s).
The API provider responds with a new access token and refresh token to be used at the next refresh.
Before you can authenticate an element instance, you must register your application with the API provider. Each registration is assigned some form of an API key (client id, client key, etc.) and secret. In Cloud Elements, these are the OAuth API Key and OAuth API Secret. You also usually need to provide a redirect URI which should match what you include in the OAuth Callback URL. If you want users to authenticate through Cloud Elements as opposed to programmatically through APIs in your application, use https://auth.cloudelements.io/oauth
.
Some API provider require scopes let you limit the authorization to a subset of the data. When users grant authorization, they are shown the scopes and acknowledge that they grant access to them. The user must allow access to all or to none. The scopes that you set up in the application should match the OAuth Scope.
The JSON used to authenticate an element instance looks like this:
{
"element": {
"key": "<The Element Key>"
},
"providerData": {
"code": "<AUTHORIZATION_GRANT_CODE>"
},
"configuration": {
"oauth.callback.url": "<CALLBACK_URL>",
"oauth.api.key": "<CONSUMER_KEY>",
"oauth.api.secret": "<CONSUMER_SECRET>",
"oauth.scope": "<COMMA_SEPARATED_LIST>"
},
"tags": [
"<Add_Your_Tag>"
],
"name": "<INSTANCE_NAME>"
}
OAuth 1.0 is an older version of the OAuth protocol. Like OAuth 2.0, the OAuth 1.0 protocol lets external applications — your application or Cloud Elements — request authorization to access and update a users data without asking users for sensitive user names and passwords. OAuth 1.0 is also flexible with multiple different ways to implement it.
This section describes how Cloud Elements supports the OAuth Core 1.0 Revision A authentication flow. The typical OAuth 1.0 authorization flow is a three-legged authentication process:
The typical OAuth 1.0 flow as supported by Cloud Elements includes the following steps:
Before you can authenticate an element instance, you must register your application with the API provider. Each registration is assigned some form of an API key (client id, client key, etc.) and secret. In Cloud Elements, these are the OAuth API Key and OAuth API Secret. You also usually need to provide a redirect URI which should match what you include in the OAuth Callback URL. If you want users to authenticate through Cloud Elements as opposed to programmatically through APIs in your application, use https://auth.cloudelements.io/oauth
.
The JSON used to authenticate an element instance looks like:
{
"element": {
"key": "twitter"
},
"providerData": {
"oauth_token": "<OAUTH_TOKEN_RETURNED_IN_OAUTH_EXCHANGE>",
"oauth_verifier": "<OAUTH_VERIFIER_RETURNED_IN_OAUTH_EXCHANGE>",
"secret": "<SECRET_RETURNED_IN_OAUTH_EXCHANGE>"
},
"configuration": {
"oauth.api.key": "<INSERT_QUICKBOOKS_API_KEY>",
"oauth.api.secret": "<INSERT_QUICKBOOKS_API_SECRET>",
"oauth.callback.url": "<SAME CALLBACK URL USED IN STEP 2>"
},
"tags": [
"<INSERT_TAGS>"
],
"name": "<INSERT_INSTANCE_NAME>"
}
Many API providers implement OAuth 2.0 in unique ways. When you create an element and need to deviate from the standard Cloud Elements OAuth 2.0 Flow, you can use specific endpoints to override each step in the flow. In each endpoint, use a combination of configurations, parameters, and hooks to override the standard OAuth 2.0 flow.
The resources available to override OAuth 2.0 flows are:
GET/oauth-authorize
— Overrides the first step in the OAuth 2.0 flow where Cloud Elements requests authorization on behalf of your app by redirecting a user to the API provider's Authorization URL.POST/oauth-token-exchange
— Overrides the second step in the flow where Cloud Elements exchanges the code returned from the API provider for an access token.POST/oauth-token-refresh
— Overrides the refresh step where Cloud Elements exchanges a refresh token for an updated access token.Overriding the OAuth 2.0 flow is a complex task and the number of ways to perform the overrides are limited only to your imagination and ability to write JavaScript code. The steps below do not provide details of how to override specific steps, but serve as a guide to get you started. See Custom Resources for general steps to add a resource to an element.
To add the GET/oauth-authorize
resource:
/oauth-authorize
.Select only the GET method.
Your new resource should like:
Click Go.
Find the endpoint, and then click .
Change the description to something like: "Overriding the OAuth 2.0 authorization".
From Resource Type, select OAUTH ON AUTHORIZE URL.
Some common configurations that you can use in the parameters of the endpoint or in the hooks to manipulate the request include:
oauth.api.key
)oauth.api.secret
)oauth.callback.url
)oauth.authorization.url
)oauth.scope
)To add the POST/oauth-token-exchange
resource:
/oauth-authorize
.Select only the POST method.
Your new resource should like:
Click Go.
Find the endpoint, and then click .
Change the description to something like: "Overriding the OAuth 2.0 token exchange".
From Resource Type, select OAUTH ON TOKEN EXCHANGE.
Some common configurations that you can use in the parameters of the endpoint or in the hooks to manipulate the request and response include:
oauth.callback.url
)oauth.user.refresh_token
(from the response)oauth.user.token
(from the response)oauth.user.refresh_interval
)To add the POST/oauth-token-refresh
resource:
/oauth-authorize
.Select only the POST method.
Your new resource should like:
Click Go.
Find the endpoint, and then click .
Change the description to something like: "Overriding the OAuth 2.0 token refresh".
From Resource Type, select OAUTH ON TOKEN REFRESH.
Some common configurations that you can use in the parameters of the endpoint or in the hooks to manipulate the request and response include:
oauth.token.refresh_url
)oauth.token.revoke_url
)oauth.user.refresh_interval
)oauth.token.url
)oauth.user.token
(from the response)