Okta Log Streaming lets you push your audit logs to a SIEM for real-time security monitoring, but most people don’t realize it’s not just about getting logs, it’s about shaping them for maximum impact.
Let’s see Okta Log Streaming in action. Imagine you’re setting up a log stream to send Okta audit logs to Splunk.
First, you’d navigate to Security > Audit Logs in your Okta admin console and click Log Streaming.
Then, you’d click Add Log Stream.
Here’s where you configure the destination. For Splunk, you’d select Splunk from the "Log Provider" dropdown.
You’ll need to provide your Splunk HTTP Event Collector (HEC) URL, which typically looks like https://your-splunk-instance.splunkcloud.com:8088/services/collector/event. You’ll also need the HEC Token you generated in Splunk.
Crucially, you can filter the logs. This is where you shape the data. Instead of sending everything, you can specify which events matter most. For instance, you might want to capture all user.session.start and user.session.end events, but only for specific user groups or applications. This is done using Okta’s Event Hook filtering language.
A common filter might look like this:
{
"eventType": [
"user.session.start",
"user.session.end",
"user.session.reset_all"
],
"actor.alternateId": {
"matches": ".*@yourcompany.com"
}
}
This filter ensures that only session-related events for users with email addresses ending in @yourcompany.com are sent. This drastically reduces noise in your SIEM.
You can also select which event fields to include. By default, Okta sends a comprehensive set of fields. However, for efficiency and to avoid overwhelming your SIEM with redundant data, you can choose to send only the fields you actively monitor. For example, you might deselect client.userAgent if you’re not directly analyzing user agents in your SIEM.
Once configured, the log stream becomes active, and Okta begins sending events matching your criteria to your Splunk HEC in near real-time. You’d then see these events appearing in your Splunk search interface, ready for analysis.
The problem Okta Log Streaming solves is the gap between security events happening in your identity provider and your centralized security monitoring system. Without it, you’d be manually downloading audit logs, which is neither scalable nor timely. It bridges this gap by providing a continuous, automated flow of critical security telemetry.
Internally, Okta uses webhooks to push log data. When an event occurs that matches your log stream’s filters, Okta formats the event data into a JSON payload and sends it to the specified endpoint (your SIEM’s ingestion URL). The SIEM then receives this payload, parses it, and indexes it for searching and alerting.
The exact levers you control are the Log Provider (where the logs go), the Endpoint URL and Authentication (how Okta connects to your SIEM), and most importantly, the Event Filters and Included Fields. These filters are powerful; you can construct complex rules based on eventType, actor properties (like alternateId, id), target properties, outcome (success/failure), and even custom attributes if you’re using Okta’s advanced features.
One critical aspect of Log Streaming is understanding the order of operations within Okta’s event processing. Filters are applied before the log is sent. This means if you create a filter that looks for eventType user.session.start and outcome FAILURE, and then in the "Included Fields" section you exclude the outcome field, the event will still be filtered out correctly (because the outcome field was evaluated before exclusion), but the outcome field itself won’t be present in the logs that do get sent. This distinction is vital for debugging why certain events might not be appearing in your SIEM as expected.
The next concept you’ll encounter is transforming and enriching these logs within your SIEM to create effective detection rules.