Summary
It would be very useful if Access could natively export or stream its audit logs to an external destination such as AWS S3, which could then serve as a staging point for downstream SIEM ingestion.
Motivation
Currently, audit logs are available through the UI and API, but there is no built-in way to continuously export them. Many organizations already have pipelines that pull logs from S3 into Splunk, Datadog, Chronicle, or Elastic. Without a direct stream, teams need to either poll the API or rely solely on Okta’s system logs, which do not always include the same level of Access-specific detail.
Proposed solution
• Add a configurable log streaming backend, with S3 as the first target.
• For each new audit entry, write JSON (or newline-delimited JSON) objects to S3 with a configurable bucket and prefix.
• Optionally support pluggable backends in the future (e.g., GCS, Azure Blob, Kinesis, Kafka).
Benefits
• Provides a simple, vendor-agnostic way to ship Access audit data into existing security pipelines.
• Enables compliance teams to centralize auditing in their SIEM without building custom collectors.
• Reduces load from polling APIs and lowers risk of missing events.
Alternatives considered
• Polling /api/audit/... endpoints and shipping results manually (works but is brittle, adds maintenance burden).
• Relying exclusively on Okta System Logs (useful, but may not capture all Access context or fine-grained actions).
Additional context
A simple S3 sink would already cover the majority of enterprise use cases. From there, teams can leverage their existing ETL/SIEM ingestion tooling.
Summary
It would be very useful if Access could natively export or stream its audit logs to an external destination such as AWS S3, which could then serve as a staging point for downstream SIEM ingestion.
Motivation
Currently, audit logs are available through the UI and API, but there is no built-in way to continuously export them. Many organizations already have pipelines that pull logs from S3 into Splunk, Datadog, Chronicle, or Elastic. Without a direct stream, teams need to either poll the API or rely solely on Okta’s system logs, which do not always include the same level of Access-specific detail.
Proposed solution
• Add a configurable log streaming backend, with S3 as the first target.
• For each new audit entry, write JSON (or newline-delimited JSON) objects to S3 with a configurable bucket and prefix.
• Optionally support pluggable backends in the future (e.g., GCS, Azure Blob, Kinesis, Kafka).
Benefits
• Provides a simple, vendor-agnostic way to ship Access audit data into existing security pipelines.
• Enables compliance teams to centralize auditing in their SIEM without building custom collectors.
• Reduces load from polling APIs and lowers risk of missing events.
Alternatives considered
• Polling /api/audit/... endpoints and shipping results manually (works but is brittle, adds maintenance burden).
• Relying exclusively on Okta System Logs (useful, but may not capture all Access context or fine-grained actions).
Additional context
A simple S3 sink would already cover the majority of enterprise use cases. From there, teams can leverage their existing ETL/SIEM ingestion tooling.