Skip to main content


The Okta Matano managed log source lets you ingest your Okta System logs directly into Matano.


Use the managed log source by specifying the managed.type property in your log_source as OKTA.

name: okta

type: OKTA
base_url: <MY_OKTA_BASE_URL> # e.g.

For the tables you would like to enable from this managed log source, under a tables/ subdirectory in your log source directory, create a file with the name <table_name>.yml>. For example:

└── log_sources/
└── okta/
└── log_source.yml
└── tables/
└── system.yml

For a complete reference on configuring log sources, including extending the table schema, see Log source configuration.


The Okta managed log source supports the following tables:

  • system


Pull (default)

Matano integrates with your Okta account to automatically pull relevant logs on a regular basis (every 5 min).

To get started with the integration, specify the following properties in the log source configuration file:

type: OKTA
base_url: <MY_OKTA_BASE_URL> # e.g.

After the first deployment, this log source will also generate a secret in AWS secret's manager to store secrets related to this integration.


To ingest Okta system logs via S3, without polling the API specify the following properties in the log source configuration file only, without specifying a base_url to poll:

name: okta

type: OKTA

For a log source named okta, a file under the path okta/afe3c55a-8b05-4ac7-be76-b6fda08af95d/system-log.log will be routed to the system table.

S3 Path scheme to table:

  • * (all) -> system


To finish onboarding the log source, populate the api_token key in the secret generated by Matano in AWS Secrets Manager, with the value from your OAuth app.


Okta log data is normalized to ECS fields. Custom fields are normalized into the okta field. You can view the complete mapping to see the full schema.