Guidance for Okta connector

Read the following information for guidance and best practices when using an Okta connector in your flows.

Authentication

  • You must be assigned to the Okta Workflows OAuth app.

  • The necessary scopes must be granted in the Okta Workflows OAuth app. See Grant or revoke scopes.

  • You must have super admin credentials.

    In addition to the initial authorization of the connector, reauthenticating this connection requires an account with super admin privileges.

  • You also need the following information for authorizing your Okta account:

    • Domain: The domain of your Okta org, without the https:// prefix or the -admin portion of the URL. For example, if your Okta Admin Console URL is https://yourcompany.okta.com, then your domain is yourcompany.okta.com.

    • Client ID and Client Secret: The client ID and client secret from your Okta Workflows OAuth app.

      You can retrieve these values through the Okta Workflows OAuth application:

      1. In the Admin Console, go to ApplicationsApplications.

      2. Open the Okta Workflows OAuth application.

      3. Click the Sign On tab and copy the Client ID and Client secret values in your Okta connection details.

Types of accounts

The account used to create the connection must have super admin credentials.

Often, it's a better practice to create a specific service account with super admin credentials for Okta Workflows and then use that account to authorize the connection. Otherwise the Okta user account used to set up the connection is associated with any actions performed by Okta Workflows.

New features and scopes

When a release of Okta Workflows adds features, or when a feature is enabled for your org, these updates can add scopes to the available scopes in the Okta Workflows OAuth app.

After a feature that provides new scopes is released or enabled, follow the steps in the Grant or revoke scopes section.

Grant or revoke scopes

To change the scopes in your Okta Workflows OAuth app, perform the following steps in the Workflows Console:

  1. Go to Applications Okta Workflows OAuth Okta API Scopes. A list of available scopes appears.

  2. Click Grant for each scope that you want to grant. Click Revoke for each scope that you want to remove.

  3. If the scope isn't listed in the Okta Workflows OAuth app, you can use the Okta API to handle this.

    1. If you don't already have one, create an API token.

    2. Manually grant the scope using the Grant consent to scope API endpoint. Or revoke the scope by calling the Revoke an app Grant API endpoint.

      See OAuth 2.0 Scopes for a list of all available scopes.

For an existing Okta connection, you must reauthorize the connection to pick up any scope changes.

List of default scopes

These are the default scopes shown in the Permissions tab of the Okta connector.

Scopes designated with an asterisk (*) are automatically granted. You don't need to grant them through the Okta Workflows OAuth app.

The connection authorization fails if you revoke any of the automatically granted scopes in the OAuth app.

Grant or revoke other scopes as required for your connection.

  • openid*
  • profile*
  • email*
  • phone*
  • address*
  • groups*
  • offline_access*
  • okta.apps.manage
  • okta.apps.read
  • okta.clients.manage
  • okta.clients.read
  • okta.clients.register
  • okta.deviceAssurance.manage
  • okta.deviceAssurance.read
  • okta.devices.manage
  • okta.devices.read
  • okta.eventHooks.manage
  • okta.eventHooks.read
  • okta.events.read
  • okta.factors.manage
  • okta.factors.read
  • okta.governance.accessCertifications.manage
  • okta.governance.accessCertifications.read
  • okta.governance.accessRequests.manage
  • okta.governance.accessRequests.read
  • okta.governance.entitlements.manage
  • okta.governance.entitlements.read
  • okta.groups.manage
  • okta.groups.read
  • okta.identitySources.manage
  • okta.identitySources.read
  • okta.idps.manage
  • okta.idps.read
  • okta.inlineHooks.manage
  • okta.inlineHooks.read
  • okta.linkedObjects.manage
  • okta.linkedObjects.read
  • okta.logs.read
  • okta.networkZones.manage
  • okta.networkZones.read
  • okta.policies.manage
  • okta.policies.read
  • okta.roles.manage
  • okta.roles.read
  • okta.schemas.manage
  • okta.schemas.read
  • okta.trustedOrigins.manage
  • okta.trustedOrigins.read
  • okta.users.manage
  • okta.users.read
  • okta.workflows.invoke.manage (Limited Early Access release)

Best practices

The following information provides more configuration information for Okta cards.

Search System Log options

  • In the Keyword field, the query parameter q is used to perform keyword matching against the attribute values for a Log Events object. All input keywords must be matched exactly (keyword matching is case-insensitive). See System Log.

  • No values are returned when using a keyword match on an attribute with a null.

  • The eq operator is used to concatenate each key and value pair, and combines different keys with an and operator. To use other operators, use the Custom Filter field to build your own expression. Those predefined fields and the Custom Filter field are concatenated using the and operator. See System Log.

Get users or groups

The following examples show configurations for obtaining both the first 200 groups and for streaming records.

First 200 records

This flow captures the first 200 groups that a user joined on a monthly basis.

  • Parent flow

  • Helper flow

Stream records

This flow updates one Custom Field value for all the groups that a specific user joined.

  • Parent flow

  • Helper flow

Related topics

Okta connector

Workflow elements

Guidance for Okta connector

Okta API documentation