Okta and Splunk

Okta Log Streaming has a Splunk Cloud target in its catalog. You create a HEC token in Splunk Cloud, set its sourcetype to OktaIM2:log so the add-on's field extractions apply, then add the log stream in the Okta admin console under Reports, Log Streaming with your Splunk Cloud host and the HEC token. That is the whole configuration.

The Splunk Add-on for Okta Identity Cloud runs modular inputs against the Okta API. The Logs metric collects the System Log; Users, Groups and Apps collect Universal Directory data. Each input has a start date, defaulting to seven days ago in UTC, so this is the path that fills historical gaps.

The add-on supports an Okta API token, OAuth 2.0 authorization code grant against an OIDC web app, and OAuth 2.0 client credentials via an Okta API Service Integration. The OAuth paths take only the scopes they need: okta.logs.read, okta.users.read, okta.groups.read and okta.apps.read. If your org has a policy against long-lived API tokens, this integration does not force you to break it.

The add-on exposes a Rate Limit Percent that caps how much of your Okta quota it will consume, recommended at 50 percent, plus a Dynamic Rate Throttling option that spaces requests out instead of firing a burst and then waiting. Page sizes are configurable too, with the Logs endpoint taking up to 1000 per request.

Splunk publishes real performance figures rather than making you guess. On a 16 core, 32 GB instance with the rate limit percentage set to 100, version 3.0.0 ingested 10,973,567 events in 13,620 seconds, about 806 events per second, where older versions took 32,968 seconds for the same set. Splunk is explicit that these are reference figures and not a promise.

The add-on ships an Okta System Logs Streaming dashboard that plots ingested events over time by host and source, specifically so you can see when streamed logs went missing, then run a modular input with a start and end date to collect just that window. It works. That it exists at all is the useful signal.

Okta documents Log Streaming as supported only on Splunk Cloud instances. If you run Splunk Enterprise on-premises, the push path is not one of the documented options and the modular input is what is left.

Splunk's wording is blunt: if Okta System Log Streaming hits an error such that it stops sending data into Splunk, that data is lost and the same data cannot be retrieved using Log Streaming. Recovery means going back to the modular input for that window, which means you need the modular input configured and credentialed before you need it, not after.

Okta tells you not to tick Enable indexer acknowledgment when you create the HEC token, because Okta log streaming does not support it. Splunk Cloud Platform would not have given it to you anyway: indexer acknowledgment there is only available for AWS Kinesis Firehose. So nothing in this pipeline ever confirms that an event was indexed.

Okta does not return System Log data older than 90 days. A backfill query that reaches past the window still succeeds and simply returns less, which is the worst possible failure mode, because a short result looks identical to a complete one.

A polling request returns events ordered by internal persistence time, not by the published timestamp, and Okta states plainly that events may come back out of order by published. Bounded requests are ordered correctly but come with their own caveat: not all events for a range may be present, because some events can be delayed. Neither mode gives you both properties.

The add-on collects only up to current UTC time minus a Logs Delay, defaulting to 30 seconds and configurable from 0 to 300, explicitly to avoid data loss from Okta system delays. Sensible engineering, but it means your Okta dashboard is never truly live and an alert threshold measured in seconds will misbehave.

Editing an input to change its start date can result in data duplication, and Splunk hides the field behind a "Use existing data input" toggle to make you think about it. Backfilling by editing a live input is how you end up counting the same failed logins twice.

Running the older Okta Identity Cloud Add-on for Splunk alongside the current Splunk Add-on for Okta Identity Cloud is unsupported and causes configuration conflicts, missing sourcetypes and ingestion gaps. Account configurations are not migrated automatically either, so a migration that looks finished may not be. Splunk gives you a search for it: group OktaIM2:log events by uuid and look for any uuid appearing under more than one source.

You have to disable inputs before upgrading the add-on. Upgrading while ingestion is in progress can lose data. Version 4.0.0 added a further trap: it strictly validates an auth_type field that accounts created before v1.2.0 never had, so long-standing accounts can fail authentication after the upgrade until you re-enter the secret and save.

Okta's rate limit quotas vary by service subscription, HTTP method, license count and add-ons such as DynamicScale. The documentation explains the bucket mechanics thoroughly and gives you no number for /api/v1/logs. Plan capacity from the rate limit dashboard and the response headers in your own org, not from the docs.