In May 2025 Okta released a Workflows connector for Identity Threat Protection with Okta AI, called the Okta ITP connector. This article is a brief walkthrough of the connector.
Introduction
With the release of Identity Threat Protection with Okta AI (ITP), new capabilities have been added to the Okta Workforce Identity platform for risk evaluation/detection and remediation. This includes new events written to the Okta System Log, new APIs (such as endpoints to see/manage user risk), and new functionality such as universal logout.
In May 2025, Okta released the Okta ITP connector for Okta Workflows. As with any Workflows connect it obfuscates API call making it simpler to build bespoke automation processes. This article provides an introduction this connector. Note that by the time you see this article, additional events/actions may have been added – as always check the product documentation.
The Okta ITP Connector
We will look at the connector authentication, the events and actions, and show some examples.
Connector Authentication
Whist this is a new Workflows connector, it is leveraging standard Okta functions. Some of the actions could be done in the standard Okta connector.
It uses the same authentication as the standard Okta connector. This is the OpenID Connect Client ID and Client secret on the Okta Workflows OAuth app in Okta.
Depending on what events or actions you are using you may need to grant one or more of the following Okta API Scopes on the Okta Workflows OAuth app:
- okta.events.read
- okta.riskProviders.manage
- okta.riskProviders.read
- okta.sessions.manage
- okta.sessions.read
- okta.userRisk.manage
- okta.userRisk.read
- ssf.manage
- ssf.read
Some of these are tied to specific events/actions, and some will be required if you use the Custom API action. You may have some already granted due to workflows you’ve built in the Okta connector.
Connector Events and Actions
Borrowing from the product documentation, here are the events.
| Event | Description |
|---|---|
| Policy Reevaluate Auth Failed | Run a flow when an authentication policy reevaluation results in a policy violation. |
| Universal Logout | Run a flow when an admin or system account triggers Universal Logout against an app instance. This event identifies when apps have had Universal Logout triggered for audit or debugging purposes. |
| User Risk Detected | Run a flow when Okta detects that a user is associated with risk activity or context. |
Using any of the these three system log events means that you can have your workflow listen for the events rather than having your workflow use an API Endpoint and setting up an event hook. It also handles parsing out the important data fields for the event rather tham having to do it yourself in the workflow (and example of this below).
Of course if you want to trigger a workflow off other ITP events in the system log, you will need to build the workflow with an API Endpoint and data parsing, tied to an event hook.
There are four actions.
| Action | Description |
|---|---|
| Custom API Action | Make an authenticated HTTP request to the Okta API. |
| Global Token Revocation | Initiate the global revocation of all tokens and sessions for a specified user. This enables external identity providers (IdPs) to trigger a comprehensive sign-out process, including executing IdP-initiated sign-out flows across all apps that are using global token revocation and requiring users to re-authenticate to access protected resources. |
| Retrieve User Risk | Retrieve the user risk object for a specified user ID. |
| Upsert User Risk | Upsert (create or update) the user risk object for a specified user ID. |
The Custom API action is the same as the one for the Okta connector so you could theoretically run any Okta API through it.
The Global Token Revocation action is useful when you want to mix universal logout with some other bespoke action. There is an example of this below.
The other two can be used to determine the current risk level of a user (perhaps you want to query it from some other process) and set it to Low or High.
Some Examples
These examples have been taken from Using Risk in Okta to Manage Privileged Access in OPA.
In the first example, we are triggering a workflow on a user.risk.detect event (i.e. user risk change) to manage users in risk-related groups. The Okta ITP User Risk Detected event card is added to the start of the flow.
It parses out all of the relevant information from the system log event, like the Risk object and Okta User object.
The second example there is a need for some bespoke processing for universal logout. In response to an entity risk policy being fired, the user needs to be logged out of their active sessions that Okta can do, but also needs to perform some custom action on a specific application.
In this case the workflow is a Delegated Flow attached to the ER policy. It will perform the Global Token Revocation action and then proceed to the bespoke steps for the specific application.
These examples show how the different events and action cards can be used to expand user risk-related bespoke automation flows.
Conclusion
The new Okta ITP connection for Okta Workflows means that bespoke automation can be built to leverage the risks detected by ITP and user risk levels changed by ITP. The article has provided a summary of the authentication, events and actions, and provided some example uses of these.
IAMSE