Skip to content

Okta identity inventory

Okta supplies identity and group context so Venturi can map AI usage to the right person, team, and admin review queue without storing prompt or completion content.

Onboarding scope

This guide covers the read-only okta connector in the Venturi platform connector package: identity inventory setup and validation. SCIM provisioning and SSO administration are documented separately in SCIM provisioning and Single sign-on.

Required access

Grant these Okta OAuth 2.0 scopes. They are vendor permissions, entered exactly as written:

Okta scope Purpose
okta.users.read Read user profile, status, and lifecycle metadata for attribution context.
okta.groups.read Read group membership and team context.
okta.logs.read Read System Log authentication events used as sign-in context.

Do not grant write scopes. Venturi does not need user, group, policy, or app mutation permissions.

Use an OAuth 2.0 service app that authenticates with a private key (private_key_jwt), holds only the scopes above, and has the Read-only Administrator role (READ_ONLY_ADMIN) assigned. Okta requires an admin role for every service app, so the granted scopes and the assigned role together form the read-only boundary. Confirm that the Public client app admins org setting (in the Okta Admin Console, Settings, then Account) is off: when it is on, Okta automatically assigns the Super Administrator role to a service app after its scopes are granted. If Okta already assigned that role, remove it so the app holds only Read-only Administrator.

An Okta API token (the SSWS scheme) works differently: it carries no scopes and inherits the privilege level of the administrator account that created it. Use one only if you cannot use a service app, and then create it while signed in as a dedicated service account that holds only the Read-only Administrator role, so the token inherits read-only privileges. Okta expires a token that goes unused for 30 days. See Okta’s service-app guide, OAuth 2.0 scope reference, standard admin roles, and API token guidance.

Setup

  1. In Okta, create a dedicated OAuth 2.0 service app for Venturi with public and private key client authentication.
  2. On the app’s Okta API Scopes tab, grant only the three read scopes above, then assign the Read-only Administrator role to the app.
  3. Record the Okta org URL and client ID, and store the private key as an encrypted credential reference in Settings / Admin / Credentials.
  4. In Venturi, go to Integrations / Okta, enter the org URL and credential reference, and run Test connection.
  5. Confirm the first sync shows users, groups, and a last-sync timestamp.

The first sync reads the full directory and the last 7 days of System Log events, because Okta defaults the System Log since parameter to 7 days before the request time when none is given. Later syncs read the users changed since the previous sync, re-read groups and memberships, and read System Log events from the last recorded event onward. Okta’s System Log API reference documents the default. See sync windows and failure behavior.

Verification

  • Test connection passes the read-only boundary check: user, group, and System Log reads succeed, and the credential holds no user, group, policy, or app mutation permission.
  • The service app’s Admin Roles tab lists only Read-only Administrator, with no Super Administrator assignment.
  • User and group counts are non-zero and match your expected tenant scope.
  • Suspended or deactivated users are marked inactive and stay in historical attribution records.
  • The connector inventory marks Okta as read-only.
  • Coverage & unknowns no longer lists identity inventory as a would-close source for connected teams.

Rotation and offboarding

Rotate the service app’s key pair, or the API token if you use one, on the same cadence as your other read-only SaaS connector credentials, then update the credential reference in Settings / Admin / Credentials. To offboard, deactivate the service app, or revoke the token on the Tokens tab of Security → API in the Okta Admin Console. If you remove the connector, existing historical attribution remains auditable, but new workforce joins, moves, and leaves stop updating until the connector is restored.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Okta identity inventory
Page: https://docs.venturi.systems/connectors/okta/