When a prebuilt connector is unavailable, Okta Workflows uses HTTP function cards to make authenticated Basic, OAuth 2.0, or custom connections to third-party services. The HTTP cards securely store credentials and automatically create a header using the selected authentication type.

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

What HTTP methods are available for authenticated connections?

Okta Workflows creates authenticated connections that can leverage several HTTP methods.

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

Configure the authentication type for an HTTP card.

Navigate to the Okta Workflows console, select an HTTP card, and configure the authentication type and connection details.

1. In the Okta Workflows console, select Function > API Connector (HTTP).
2. Select an HTTP card.
3. Click + New Connection to open the New Connection dialog.
4. Enter a nickname for the connection.
   • NOTE: 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 menu.
   • NOTE: 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.

What are the available authentication types and their fields?

Review the specific fields and requirements for each available authentication type to ensure proper configuration.

• Basic: Simple username and password scheme built into the HTTP protocol. Okta 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 exposing credentials to Okta Workflows. Before beginning the OAuth 2.0 process, register a new application with the service, including basic information such as application name and website. Register a redirect URI to redirect authentication back to Okta 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.
  • Authentication Code grant type 
    • Authorize Path: The authorization path for the service. For example, https://<example>.com/oauth2/v1/authorize.
    • Access Token Path: The URI where Okta Workflows exchanges authorization codes for access and refresh tokens.
    • Scope: Specifies the level of access provided to Okta Workflows. Multiple scopes are often space or comma-separated, depending on the service.
    • Client ID: A publicly exposed string provided by the service that identifies the OAuth 2.0 application and builds authorization URLs.
    • Client Secret: A private value provided by the service used to authenticate the identity of the application to the service.
  • Client Credentials grant type
    • Client Credentials: Client Credentials is a grant type of the OAuth 2.0 protocol. This grants full and non-user-specific access to third-party resources. 
      • Access Token Path: The URI where Okta Workflows exchanges 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 2.0 application and builds authorization URLs.
      • Client Secret: A private value provided by the service that authenticates the identity of the application to the service.
      • Client Authentication Type: Credentials can be sent as basic auth header (client_secret_basic) or basic auth body (client_secret_post) 
• Custom: Selecting Custom Header allows the creation of a custom header name and value.
  • Header Name: A custom name 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 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 also accesses unauthenticated endpoints.

Related References

• Using the Okta Workflows API Connector with OAuth 2.0