Authenticate with HTTP Cards

Overview

Use HTTP function cards to make authenticated basic, OAuth 2, or custom connections to third party services.

Background

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

HTTP Methods

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

  • Raw Request

  • Close

  • Delete

  • Get

  • Post

  • Put

Authentication Types

To set up your authentication:

  1. In the Workflows console, select Function > HTTP.

  2. Select an HTTP card.

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

  4. Enter a nickname for your 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. "JIRA Service Desk - OAuth - serviceaccount", for example.

  5. Select your 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 your 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 you to grant limited access to resources on a third party site without having to expose your credentials to Workflows. Before beginning the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, etc. In addition, you must 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 code 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

  • Custom: Selecting Custom Header allows you to create 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 your connection when none of the other options apply. It can also be used to access unauthenticated endpoints.

Note: Connections are not tested automatically in the HTTP cards as they are when using prebuilt connector. To test your connection, use the Test this card functionality in a flow.