This short post is for the information of people who may look at some of the older OIG API and Workflows articles on this site and find they no longer work. You should be using the Okta Connector with the Custom API Action card now instead of the old generic API Connector card.

The OLD Way to Use OIG APIs in Workflows

When we first started writing articles on how to extend Okta Identity Governance (OIG) with APIs and Workflows, the Okta Workflows OAuth app had not been updated to include the OIG API scopes. This meant that you needed to use the generic API Connector.

The following figure is an example of this:

The flow shown here is fairly standard:

1. Setup the Authorization object (SWSS <token>) using a subflow with a token tied to an admin user in Okta
2. Setup the URL for the generic API call, that includes the https:// and the Okta org domain name, with the API endpoint relative URL
3. Construct a query object and/or body object depending on the needs of the API
4. Call the API Connector card passing in the full URL, query/body objects and the authorization object

The key here is setting up the authorization object and the full URL.

The NEW Way to Use OIG APIs in Workflows

The Okta Workflow OAuth app was updated a while back to include the governance scopes. If you try to run the old method you may find workflows failing with a 401 Unauthorized error (errorCode “E0000011” errorSummary “Invalid token provided”). This is an indication you need to update your flows to use the Okta Connector with the Custom API Action card.

There are two things to be done: enable the relevant scopes for the app and update your flows.

Enable Okta API Scopes in Okta Workflows OAuth App

First, there are multiple Okta API Scopes that can be granted in the Okta Workflows OAuth app. They are fairly generic – read or manage for the three types of functions (access certs, access requests and entitments).

There are also four new scopes introduced for the new Resource Catalog approach to access requests.

You will need to grant the level of access to the API calls you want to make in workflows.

Once you update the scopes in the app, you will need to reauthenticate the connection in Workflows.

Note that there is only one OAuth app, so you will need to grant the highest level of access to cover any API call you will make across all of your workflows, and any workflow could use higher level permissions than they need. You should apply controls around who is building flows and what APIs they are including in the flows.

Use the Okta Connector with Custom API Action in Workflows

With the scopes granted, you can update your flows to use the Custom API Action card from the Okta Connector.

Here is the flow from above, but changed to use the new method.

Changes from the old approach:

• You no longer need to use an API token and setup the authorization object – the Okta connector handles this
• The URL passed into a Custom API Action card is the relative URL (e.g. /governance/api/v1/requests) not the full URL
• The query/body arguments are the same.

The output is the same for both (Status Code, Headers and Body), so your processing of the response won’t change.

This approach is much cleaner. You don’t need to worry about storing an API token somewhere (like in a table or hardcoded into a flow) and you don’t need to worry about updating the token when it expires. Also you don’t need to worry about the okta URL as it’s also tied to the connector, making the flows more portable.

Hopefully this gives you enough information on updating your flows to the new method of making OIG API calls from Workflows.