While most implementations of OAuth are very similar, OAuth 2.0 is an extensible framework, and some vendor's implementations may not fully work with the Workflows API Connector. This article answers several common questions about how the Workflows API Connector supports creating OAuth 2.0 connections for third-party services.
Table of Contents
What versions of OAuth does the API connector support?
What OAuth Grant Types does the API Connector support?
What if I need to use an unsupported OAuth Grant Type in Workflows?
Does the API Connector support using Refresh Tokens?
Where do I get the configuration settings for creating an API connection that uses OAuth?
What Redirect URIs should be used for Workflows?
When using multiple scopes, how should they be delimited?
Can I add query parameters to the Authorization Path and Access Token Path fields?
Can I specify additional headers when creating an API connection that uses OAuth?
What versions of OAuth does the API connector support?
The API Connector supports OAuth 2.0 only.
What OAuth Grant Types does the API Connector support?
The API Connector currently supports the Authorization Code and Client Credentials grant types only. The OAuth 2.0 framework specifies several different Grant Types, also referred to as OAuth Flows, for different use cases. Grant types other than Authorization Code and Client Credentials, such as PKCE, are currently not supported by the API Connector.
What if I need to use an unsupported OAuth Grant Type in Workflows?
The API Connector cannot be used with an Auth Type of OAuth for grant types that are not supported, but it may be possible to implement the desired OAuth grant type inline in the workflow. This can be done using the API Connector with an Auth Type of None and Raw Request cards to call the authorize and token endpoints accordingly. Note that this typically involves exposing sensitive information, such as the Client ID or Client Secret, in the workflow as plain text.
Does the API Connector support using Refresh Tokens?
Yes, if the OAuth implementation for the service being used can:
-
Automatically issue refresh tokens.
-
Issue a refresh token by requesting a specific scope, like offline_access.
-
Issue a refresh token by specifying a query parameter on the authorize endpoint.
The API connector will use the refresh token to refresh an expired access token. In cases where it is not possible to get a refresh token due to the vendor's implementation of OAuth, the API connection will require manual reauthorization whenever the access token expires.
Where do I get the configuration settings for creating an API connection that uses OAuth?
To use OAuth for authorization with third-party services, register an OAuth app that uses the Authorization Code or Client Credentials grant type with the third-party service. Upon creation of an app, the unique Client ID and Client Secret are needed to configure the API connector. If required by the OAuth implementation for the third-party service, the Authorize Path, Access Token Path, and Scopes should be included in the OAuth documentation for the service.
What Redirect URIs should be used for Workflows?
When registering an OAuth app with a service that uses the Authorization Code grant, a Redirect URI (also referred to as a Callback URI or URL) must be specified for redirecting responses after successfully authenticating. Use the following Redirect URIs for Workflows Preview and Production orgs, respectively:
-
Preview: https://oauth.workflows.oktapreview.com/oauth/httpfunctions/cb
-
Production: https://oauth.workflows.okta.com/oauth/httpfunctions/cb
When using multiple scopes, how should they be delimited?
This depends on the OAuth implementation for the service being used, but scopes are typically space or comma-delimited. Refer to the OAuth documentation for the service. Note that when using Client Credentials with the API connector, specifying scopes is not supported.
Can I add query parameters to the Authorization Path and Access Token Path fields?
Some implementations of OAuth may require additional query parameters to obtain a refresh token. Adding query parameters to the Authorize Path URL is supported. However, adding query parameters to the Access Token Path is not supported.
Can I specify additional headers when creating an API connection that uses OAuth?
No, it is not possible to include additional headers when using OAuth with the API Connector. Some implementations of OAuth may require additional headers to be included in the request to the authorize and/or token endpoints. For example, an Authorization header containing a base-64 representation of the Client ID and Client Secret may be required. In this case, the API connector cannot be used with OAuth.
