Auth Configuration

We offer two types of auth configurations, URL and OAuth2. An app can have multiple auth configurations.

URL​

URL configurations are typically useful for authenticating with a company intranet or another service you control. It relies on using cookies, which are set during the login flow, with cross origin AJAX requests to authenticate the API calls. See Cross-Origin Resource Sharing (CORS): Request with Credentials for more details.

Name​

required

String name for the auth configuration. Must only contain alphanumeric characters, dashes, and underscores and be between 1 and 100 characters long. Must be unique for each auth config each app.

Login Url​

required

Url for the login page of your website. When logging in, the user will be redirected to this url, along with a redirect_uri query parameter. Upon a successful login, the user should be redirected to redirect_uri. If there are errors you want to return to the client, you can redirect the user to redirect_uri with an error query parameter. You can optionally include error_description and error_uri as query parameters to pass along more information.

Example​

Name: intranet
Login Url: https://intranet.company.com/login

OAUTH2​

We provide a generic OAuth2 implementation that will enable your app to authenicate and communicate with any third-party platforms that supports an OAuth2 API.

Name​

required

String name for the auth configuration. Must only contain alphanumeric characters, dashes, and underscores. Must be unique for each auth configuration in each app.

Authorization URL​

required

URL for the Authorization endpoint for the third-party platform.

Token URL​

required

URL for the Authorization endpoint for the third-party platform.

Redirect URL​

generated - read-only

URL for the Redirection endpoint. This url is generated using the Name field and will only show up once the auth config is complete. You should copy this url and save it in your client app configuration on the third-party-platform.

Client ID​

required

String client id for your client app on the third-party platform.

Client Secret​

required

String client secret for your client app on the third-party platform.

Scope​

optional

String access token scope for your client app on the third-party platform. It's passed as a query parameter to the authorization url during the auth flow.

Proxy API Domains​

optional

Space delimited list of URL patterns. For platforms that don't support client side API calls, we provide a server side proxy that will relay your api requests and sign them with the correct headers. This list controls what api endpoints your app is allowed to communicate with. All url patterns must be valid http or https urls.

Refresh Token Strategy​

optional

Platforms tend to differ when it comes to how to refresh an access token with a refresh token.

• NONE: this is the default. This means that you don't need to refresh access tokens, the platform doesn't support refresh tokens, or the format of the refresh token request is not supported.

• STANDARD: This implements the standard strategy as outlined in the OAuth2 spec. We send a POST request to the Token Url to refresh an access token with the following parameters:

{
    "client_id": "...",
    "client_secret": "...",
    "refresh_token": "...",
    "grant_type": "refresh_token",
}

Example​

Name:
"gdrive"

Authorization URL:
"https://accounts.google.com/o/oauth2/v2/auth"

Token URL:
"https://www.googleapis.com/oauth2/v4/token"

Client ID:
"..."

Client Secret:
"..."

Scope:
"https://www.googleapis.com/auth/drive.readonly https://www.googleapis.com/auth/drive.metadata.readonly"

Proxy API Domains:
"https://*.googleapis.com"