Collecting Okta SSO Logs with Cribl Stream

What Okta logs give you

The Okta Source page in the Cribl Stream docs describes a Source that pulls security and audit activity from the Okta System Log API, so you can filter, enrich, and route Okta events to your downstream observability and security tools. Because the Source is a Pull, the collection runs on a schedule you define rather than arriving event by event from Okta.

The page classifies the Source plainly: Type is Pull, TLS Support is Yes, and Event Breaker Support is Yes. TLS is provided via HTTPS on the underlying Okta System Log REST API, and the Source automatically handles event breaking and pagination via Okta's Link headers, so neither concern needs its own configuration.

Under the hood, the Okta Source is a managed version of the REST Collector. When a collection job runs, Cribl Stream automatically manages the complex stages of API interaction. Those stages are not individually configurable in the UI, which keeps the configuration surface small: you point it at your org with a token, define the time window, and set the schedule.

Setting up the Okta source

Before you start, the docs list three prerequisites: a Cribl Stream deployment (Cloud or self-hosted), your Okta org domain, and an Okta API token authorized for System Log access.

There are two entry paths, both starting from the top bar. Select Products, then select Cribl Stream; under Worker Groups, select a Worker Group. To configure via QuickConnect, navigate to Routing > QuickConnect, select Add Source, and choose the Source from the list, picking either Select Existing or Add New. To configure via Routes, select Data > Sources, select the Source you want, then select Add Source.

In the Source modal, the General Settings field list on the Okta Source documentation page reads as follows:

• Input ID: enter a unique name to identify this Okta Source definition. If you clone this Source, Cribl Stream will add -CLONE to the original Input ID.
• Description: optionally, enter a description.
• Okta API token (text secret): select or create a stored text secret holding the token.
• Okta domain: your Okta domain, for example your-org. Do not include .okta.com, https://, or trailing slashes.
• Cron schedule: the schedule on which to run this collection job. Defaults to */5 * * * *.
• Earliest: earliest time for data collection, relative to now. Defaults to -7d@d.
• Latest: latest time for data collection, relative to now. Defaults to now.
• Job timeout: maximum time the job is allowed to run (for example, 30, 45s or 15m). Units are seconds, if not specified. Defaults to 0, meaning unlimited time.
• Tags: optionally, add tags that you can use to filter and group Sources in Cribl Stream's UI. These tags aren't added to processed events. Use a tab or hard return between (arbitrary) tag names.

You can then optionally configure Processing Settings, Retries, and Advanced Settings. Under Connected Destinations, choose Send to Routes and/or QuickConnect depending on how you want data to leave this Source. Select Save, then Commit & Deploy.

The Cron schedule controls when export, list, and download jobs run, and the docs add one sizing detail: minimum granularity is often 10 seconds, and a default of 0 for the job timeout means no timeout at all.

The Earliest and Latest fields accept a relative time range for the events to collect, using the same syntax as other REST Sources:

[+|-]<time_integer><time_unit>@<snap-to_time_unit>

The syntax elements:

• Offset: - is past, + is future, or omit with now.
• Time integer: an integer, or omit with now.
• Time unit: now, or s, m, h, d, w, mon, q, y.
• Snap-to unit: an optional snap-to unit, introduced by @.

Two rules apply: Earliest must not be later than Latest, and values without units are interpreted as seconds (for example, -1 is -1s). The @ symbol rounds down from the evaluated time. The page gives @d as the start of the current day, and +128m@h as forward 128 minutes, then snap back to the hour boundary. Week, month, quarter, and year snaps (@w, @w1 through @w6, @mon, @q, @y) behave like other Cribl Stream Collectors.

Under Retries, you adjust how failed HTTP requests are retried. The Retry type is Backoff (default), Static, or Disabled. The Initial retry interval (ms) is the delay before the first retry after a failure, with a maximum of 20,000 ms; 0 means retry immediately until the Retry limit is reached. The Retry limit is the maximum retries per failed request: default 5, max 20, and 0 disables retries. The Backoff multiplier is the base for exponential backoff, default 2. The Retry HTTP codes defaults typically include 429 and 503, and non-2xx responses are errors. Honor Retry-After header is enabled by default and honors Retry-After up to the product maximum, so longer delays may be ignored; Stream logs the delay when applicable. The optional Retry connection timeout and Retry connection reset settings retry on ETIMEDOUT or ECONNRESET for more resilient long downloads.

Under Advanced Settings, Request timeout (seconds) is the maximum time to wait for a request, defaulting to 0, which means wait indefinitely. Time to live sets how long Collector job artifacts remain on disk and in Job Inspector (default often 4h). Environment can limit this config to a single Git branch for GitOps. Finally, to send Collect and Discover traffic through an HTTP/S proxy, you configure the System proxy settings rather than the Source itself.

Processing the events

The job stages are not individually configurable, but the page spells out the order in which each collection job executes them:

1. Authentication: connects to the Okta API using your stored secret or token.
2. Collection: pulls logs from the /api/v1/logs endpoint, automatically handling pagination via Link headers.
3. Event Breaking: automatically splits the returned JSON array into individual events.
4. Pre-Processing (Optional): applies any Pipelines or Packs you have selected in the Processing Settings.

The Processing Settings section itself offers two capabilities. Fields adds fields to each event using Eval; values can be JavaScript expressions or constants, and fields defined here normally override same-named fields on the event unless you choose to let event fields win. Pre-Processing, when Send to Routes is enabled, lets you optionally select a Pipeline (or Pack) to run on collected events before they enter Routes. That ordering matters: pre-processing shapes the events before any route in the Routing table sees them.

Cribl also attaches internal fields as metadata you can use in Functions. __collectible carries per-job metadata: collectorType, collectorId, and resHeaders when Capture response headers is enabled. __collectStats carries method, url, and elapsedMS for the Collect request. __inputId carries job identity: collection:<timestamp>.<randomId>.adhoc.<Collector ID> for ad hoc jobs and collection:<Collector ID> for scheduled ones. If a Pipeline needs to tag enriched events with the job that produced them, these fields are where that data lives.

What the docs flag

The troubleshooting section on the same page lists four failure modes worth knowing before you lean on the Source for SSO visibility:

• Non-200 HTTP responses are errors, and behavior for multi-task jobs and redirects matches the REST Collector.
• Stuck jobs: set Request timeout (seconds) in Advanced Settings and/or Job Timeout in task manifest limits.
• TypeError [ERR_INVALID_URL]: usually from over-encoding the full URL; encode only the variable segments.
• 429 Too many requests: reduce parallelism, widen schedule intervals, and respect Okta rate limits.

The practical takeaway is that failures on this Source are configuration problems, not mysteries: the timeout, the schedule density, and the retry settings above are the levers the page points at for each case.

Frequently asked questions

What data does the Cribl Stream Okta Source collect?

The Okta Source pulls security and audit activity from the Okta System Log API, so you can filter, enrich, and route Okta events to your downstream observability and security tools. The Source is a Pull type with TLS via HTTPS, and it handles event breaking and pagination via Okta's Link headers automatically.

How often does the Cribl Stream Okta Source run by default?

The Cron schedule defaults to */5 * * * *, so the collection job runs every 5 minutes. Each run collects events from the Earliest time, which defaults to -7d@d, up to the Latest time, which defaults to now.

How does the Cribl Stream Okta Source turn API responses into events?

The Source automatically splits the returned JSON array into individual events during the Event Breaking stage of each collection job. Pipelines or Packs you select in Processing Settings then run as optional pre-processing, and Cribl attaches the internal fields __collectible, __collectStats, and __inputId as metadata you can use in Functions.

What do the docs say about 429 responses from the Okta API?

The docs flag Non-200 HTTP responses as errors, and for 429 Too many requests they say to reduce parallelism, widen schedule intervals, and respect Okta rate limits. The Retry HTTP codes defaults typically include 429 and 503, so those failures are also subject to the retry settings described above.