Skip to main content

Okta Data Connector

Ingest Okta identity, authentication, and threat events into Torq to power automated analysis.

Overview

The Okta data connector provides a native, polling-based ingestion mechanism that continuously brings Okta system log events into Torq for use in workflows and Auto Triage.

Integrations and data connectors

Torq supports two approaches to connecting with Okta:

  • Integration: A custom approach to pulling data from Okta. Requires additional work such as transformation, deduplication, and routing logic to make the data usable within workflows. See Okta Integration.

  • Data connector: A plug-and-play solution that handles ingestion, transformation, deduplication, and related logic out of the box, with minimal setup required. This article covers the Okta data connector.

Key benefits

  • Simplified setup: Configure ingestion through a guided UI without building custom polling logic, handling OAuth flows, or implementing deduplication.

  • Continuous event ingestion: Okta events are retrieved automatically every 5 minutes, ensuring a steady flow of identity and security data into Torq.

  • Historical backfill: During setup, configure a lookback window (up to 14 days) to ingest past events and immediately populate Auto Triage or downstream processing.

  • Event type selection: Ingest Authentication Events, Security Events, and Identity Threat Protection (ITP) Events, any combination.

  • Built-in reliability: Handle pagination, rate limits, state tracking, and duplicate detection automatically to ensure consistent and accurate ingestion.

Common scenarios

Automated triage and case creation from Okta events

The Okta data connector enables security teams to automatically route authentication and security events into Auto Triage. Events are enriched, analyzed, and converted into investigation cases, consolidating identity signals, risk context, and activity history into a single workspace for efficient analysis.

Identity threat detection and response

Identity Threat Protection (ITP) events such as session hijacking, credential abuse, and anomalous behavior are ingested into Torq, enabling automated triage and coordinated response across identity, endpoint, and network signals.

Identity lifecycle monitoring and automation

User lifecycle events, such as provisioning, deprovisioning, permission changes, and administrative actions, can be ingested and used to trigger compliance workflows, access reviews, and identity governance automation.

Prerequisites

Before setting up the Okta data connector, ensure the following requirements are met:

  • Okta subscription: Access to the Okta System Log API is required.

  • (Optional) Identity Threat Protection: Required only if you plan to ingest ITP events.

  • API Services application: Create an API Services app in the Okta Admin Console.

  • Authentication setup: Generate an RS256 key pair and configure the application to use private_key_jwt.

  • Permissions and roles:

    • Grant the okta.logs.read scope

    • Assign the Report Admin role

  • Required credentials:

    • Okta Domain (e.g., company.okta.com)

    • Client ID

    • Private Key (PEM)

How to use

Create an API client in Okta

Open the Admin Console

Create an API Services application

  1. Navigate to applications: Go to Applications > Applications > Create App Integration.

  2. Select app type: Choose API Services (machine-to-machine authentication using OAuth 2.0).

  3. Create application: Enter a meaningful name and click Save.

Configure client authentication (private key)

The connector uses OAuth 2.0 client credentials with a JWT signed by an RSA private key (not a client secret).

  1. Enable JWT authentication: In the app settings, configure client authentication using a public key / JWT (wording varies by Okta UI version).

  2. Add signing credential: Upload your public key or register a JWK.

  3. Store private key: Keep the corresponding RSA private key (PEM format), this will be required during Torq setup.

Collect client ID

  • Copy client ID: From the application overview, copy the Client ID for later use.

Disable Proof of Possession (DPoP)

  1. Open General Settings: Go to the app’s General tab.

  2. Disable DPoP: Ensure Require Demonstrating Proof of Possession (DPoP) is unchecked.

  3. Save changes: Click Save.

DPoP must remain disabled, otherwise authentication requests from the connector will fail.

Grant System Log scope

The okta.logs.read scope grants API access to the System Log. The Report Administrator role is also required; without it, the connector cannot query log data even with the scope granted.

  1. Open API scopes: Go to the app's Okta API Scopes tab.

  2. Grant scope: Locate okta.logs.read and click Grant. Confirm admin approval if prompted.

  3. Open Admin roles: Go to the app's Admin roles tab and click Edit assignments.

  4. Assign the role: Click + Add assignment, select Report Administrator from the Role dropdown, then click Save Changes.

(Optional) Identify your Okta domain

  • Your Okta domain is your org hostname (e.g., company.okta.com, dev-12345.okta.com).

  • Enter the domain in Torq without the https:// prefix.

Set up the connector in Torq

  1. Navigate to connector: Go to Integrations > Okta Data Connector > Add Instance.

  2. Enter connection details: Provide the Instance Name, Okta Domain, Client ID, and Private Key (PEM).

  3. (Optional) Configure backfill: Set a backfill period (up to 14 days) to ingest historical events.

  4. Select event filters: Choose Authentication Events, Security Events, and/or Identity Threat Protection (ITP) Events.

  5. Select routing destination: Choose where ingested events will be sent:

    • Workflows

    • Auto Triage

  6. Save configuration: Save the connector to start ingestion. The connector automatically begins polling every 5 minutes.

When you edit an existing Okta instance, the past data ingestion period cannot be changed. To change it, delete the instance and create a new one.

You’ve successfully set up the Okta data connector in Torq. With the instance configured, Torq will continuously ingest Okta system log events and automatically trigger Auto Triage based on those events.

Conditional filters

Conditional filters limit which events are ingested from the connector. Only events that match all defined conditions are passed, reducing noise and preserving ingestion quota.

Each condition consists of a field reference and an operator. Some operators require an additional value. Conditions are joined by AND or OR logic, selected when adding each new condition.

Add a condition

Use conditional filters to control which events are processed based on field values.

  1. Add a condition: Click + and select AND or OR to define how it relates to the previous condition.

  2. Enter a field reference: Type the field path in the left input, for example {{ $.event.securityContext.risk.level }}.

  3. Select an operator: Choose from the dropdown: Equals, Not Equals, Is In, Is Not In, Contains, Not Contains, Regex Match, Regex Not Match, Is Empty, Not Empty.

  4. Enter a value: If the operator requires a value, enter it in the field below, for example ["HIGH"].

To remove a condition, click the Delete icon on the right of the condition row.

Example

The following configuration ingests only events where securityContext.risk.level is not empty, and its value is HIGH:

  • {{ $.event.securityContext.risk.level }}: Not Empty

  • AND {{ $.event.securityContext.risk.level }} Is In ["HIGH"]

Default risk ingestion

By default, the Okta connector ingests only High risk events. Medium and Low risk events are filtered out before reaching Auto Triage.

The filter uses Okta's own risk assessment (securityContext.risk.level), which Okta attaches to System Log events such as sign-ins and access activity. High is the top of Okta's risk scale, so this default forwards the most severe identity risks while suppressing lower-confidence noise.
This threshold can be adjusted per connection instance if you need to include lower-risk events for a specific source.

Risk level

Ingested

High

Yes

Medium

No

Low

No

Related Articles
Did this answer your question?