• Okta Classic Engine
• Okta Identity Engine (OIE)
• Okta Workflows
• Custom API Connection

If a prebuilt connector is not available, use HTTP cards to make a request to a third-party service and parse the response in the flow. The credentials are stored securely, and a header is created automatically using one of the provided authentication types.

1. HTTP Methods

With the HTTP functions, create authenticated connections using several HTTP methods:

• Raw Request
• Close
• Delete
• Get
• Post
• Put

2. Authentication Types

To set up the authentication:

1. In the Workflows console, select Function > API Connector (HTTP).

2. Select an HTTP card.

3. Click the + New Connection button to open the New Connection dialog.

4. Enter a nickname for the connection

   • Since the HTTP cards can be used with multiple connections, it is best practice to enter a detailed name to distinguish each connection that includes the service being called, the type of authentication, and a reference to the account being used (for example, JIRA Service Desk - OAuth - serviceaccount).

5. Select the Auth Type from the dropdown.

   • The HTTP cards support three types of authentication out of the box: Basic, OAuth, and Custom Header.

6. Populate the requested values depending on the Auth Type selection.

7. Click Create.

The fields for each type are listed below.

• Basic: Simple user name and password scheme built into the HTTP protocol. Workflows sends HTTP requests with the Authorization header containing the word Basic followed by a space and a base64 encoded string of “username:password”.

  • Username: username for the third-party application

  • Password: password for the third-party application

• OAuth: OAuth 2.0 is a protocol that allows granting limited access to resources on a third-party site without having to expose credentials to Workflows. Before beginning the OAuth process, first, register a new app with the service. When registering a new app, register basic information such as application name, website, etc. In addition, register a redirect URI to be used for redirecting authentication back to Workflows. Use the following Redirect URIs to connect to Okta Workflows Preview and Prod respectively: https://oauth.workflows.oktapreview.com/oauth/httpfunctions/cb and https://oauth.workflows.okta.com/oauth/httpfunctions/cb.

  • Authorize Path: the authorization path for the service. For example, https://<example>.com/oauth2/v1/authorize.

  • Access Token Path: the URI where Workflows can exchange authorization codes for access and refresh tokens

  • Scope: specifies the level of access provided to Workflows. Multiple scopes are often space or comma-separated, but this can depend on the service.

  • Client ID: a publicly exposed string provided by the service that is used to identify the OAuth application and build authorization URLs

  • Client Secret: a private value provided by the service used to authenticate the identity of the application to the service

• Client Credentials: Client Credentials is a grant type of the OAuth 2.0 protocol. This allows to grant full and non-user specific access to third-party resources. As with the OAuth option, first register a new app with the service including information such as the application name and website URL.

  • Access Token Path: The URI where Workflows can exchange an authorization code for access and refresh tokens. For example, https://<example>.com/oauth2/v1/token.

  • Client ID: A publicly exposed string provided by the service that identifies the OAuth application and is used to build authorization URLs.

  • Client Secret: A private value provided by the service that authenticates the identity of the application to the service.

  • NOTE: Credentials are sent in the request body and not as a Basic authorization header. If it is required by the 3rd party to have the Credentials sent in the header, then a Custom Connector would need to be built using Connector Builder. See Use OAuth 2.0 Client Credentials.

• Custom: Selecting Custom Header allows the creation of a custom header name and value.

  • Header Name: a custom name to be passed to the service. For example, a service may require “api_key” as the header name and the key itself as the value.

  • Header Value: the value to be passed to the service along with the Header Name

• None

  • Use this option to manually create the connection when none of the other options apply. It can also be used to access unauthenticated endpoints.

Related References

• Use OAuth 2.0 Client Credentials