Skip to main content

Okta Context Connector

Learn how to ingest Okta identity and access data into Torq to build organizational context for alert enrichment and investigation.

Overview

The Okta context connector builds a picture of your users, groups, applications, enrolled devices, and admin roles into Torq's organizational Context Graph. This gives Torq the context it needs to enrich alerts, support investigations, and power the Context Graph page.

Key benefits

  • Simplified setup: Configure ingestion through a guided UI, no custom polling workflows or API logic required.

  • Richer triage: Auto Triage uses the context graph to enrich alerts with user identity, group memberships, admin roles, and MFA status, helping analysts judge severity faster.

  • Flexible scoping: Ingest only the data streams relevant to your Okta configuration and use case.

  • Built-in reliability: Pagination, state tracking, and error handling are managed automatically to ensure consistent data delivery.

This is a context and enrichment connector; it builds a picture of your users, devices, and access into Torq's organizational Context Graph. It does not route alerts or events into Torq for triage. Detection routing is handled by the Okta data connector.

Common scenarios

The same Context Graph powers multiple use cases, regardless of which vendors are connected.

Improving alert triage with organizational context

When an alert involves a user or device, Auto Triage enriches it with context from the Context Graph, including identity, role, group memberships, device ownership, management status, and access privileges. This context is incorporated into the triage verdict and displayed in the alert's Context Graph section, helping analysts assess risk more quickly. For example, an alert involving a privileged admin on an unmanaged device may warrant a different response than one involving a standard user on a managed corporate device.

Investigating entities and relationships

The Context Graph page is where analysts can explore users, devices, accounts, and their relationships without switching between vendor consoles. Common questions include:

  • Who owns this device, and is it managed?

  • Which groups and applications does this user belong to?

  • What resources can this account access?

  • How are these entities connected?

By centralizing organizational context, the Context Graph enables faster investigations and more informed security decisions.

Prerequisites

Before setting up the Okta context connector, ensure the following:

  • Okta subscription:

    • User, group, app, MFA factor, and role data: Available on all Okta tenants.

    • Device data: Requires Okta Device Trust, Okta FastPass, or Okta Verify enrollment. Tenants without these configured return an empty device list; all other data streams are unaffected.

  • API service app: Create an API Services application in the Okta Admin Console prior to configuration.

  • API scopes: The service app must be granted the following Okta API scopes:

    • okta.users.read, for users and per-user MFA factors

    • okta.groups.read, for groups

    • okta.apps.read, for the app catalog

    • okta.devices.read, for enrolled devices

    • okta.roles.read, for per-user admin role assignments

How to use

Create an Okta API service app

  1. Log in: Go to your Okta Admin Console and log in with an admin account.

  2. Create an app integration: Go to Applications > Applications and click Create App Integration.

  3. Select app type: Choose API Services and click Next.

  4. Name the app: Give it a descriptive name (e.g., Torq Integration) and click Save.

  5. Copy the Client ID: From the app's General tab, copy the Client ID. You will need this during Torq setup.

  6. Configure client authentication: On the app's General tab, under Client Credentials, set Client authentication to Public key / Private key and enable Client Credentials as the grant type.

  7. Generate a key pair: On the app's General tab, under Public keys, click Add key, then Generate new key. When Okta displays the key, download it in either PEM or JSON format, Torq accepts both. The key is shown only once. Keep exactly one key on the app.

  8. Disable Proof of Possession: On the app's General tab, under General Settings, leave Require DPoP header unchecked.

  9. Grant API scopes: Go to the Okta API Scopes tab and grant the following scopes: okta.users.read, okta.groups.read, okta.apps.read, okta.devices.read, okta.roles.read.

  10. Assign admin roles: API scopes allow the app to call the API. Admin roles determine what data it can actually read. On the app's Admin roles tab, assign both of the following:

    • Read-only Administrator (standard role): covers users, groups, apps, devices, MFA factors, and device-user links.

    • Custom admin role: required for admin-role assignments (/users/{id}/roles) and the role catalog (/iam/roles). To create it:

      1. Go to Security > Administrators > Resource, create a new resource set, and include the Identity and Access Management resource.

      2. Go to Security > Administrators > Roles, create a new custom role with permission to view roles and admin-role assignments.

      3. Assign the custom role: Go back to Applications > Applications and select the app you created. On the Admin roles tab, click Edit assignments, then Add assignment, and select the role and resource set you created in the previous steps.

        When complete, the app's Admin roles tab should show two assignments: Read-only Administrator and your custom role (e.g.,

        Torq Role), each scoped to a resource set.

Set up a context connector instance in Torq

  1. Open connector setup: Go to Integrations > Context Graph > Okta Context Connector and click Add Instance.

  2. Configure connection details:

    • Instance name: Enter a descriptive name for the connector instance.

    • Okta Domain: Enter your Okta org URL without a scheme (e.g., my-company.okta.com).

      Do not use the Okta admin URL. The admin URL (my-company-admin.okta.com) will not work. Use the org URL only (my-company.okta.com).

    • Client ID: Enter the client ID copied from the Okta app's General tab.

    • Private key: Attach the private key file downloaded during Okta app setup. Both PEM and JSON formats are accepted.

  3. Save configuration: Click Add to create the connector. Ingestion starts automatically.

You've successfully set up the Okta context connector in Torq. With the instance configured, Torq will continuously ingest Okta identity and access data, including users, groups, applications, devices, MFA factors, and admin role assignments, into the Context Graph. This context is available immediately for alert enrichment in Auto Triage and for investigation in the Context Graph page.

  • If a selected data stream is unavailable due to a missing scope or unsupported configuration, Torq skips that stream and continues ingesting the rest. Only the unavailable subset is missing; other data is unaffected.

  • The connector stays within Okta’s per-app rate limit. To use less of it, set a lower rate limit for the connector’s app in the Okta Admin Console (Reports > Rate Limits)

Did this answer your question?