> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-3.x/cortex-xdr-3.x-documentation/data-management/data-ingestion/external-data-ingestion/ingest-authentication-logs-and-data/ingest-logs-and-data-from-okta.md).

# Ingest Logs and Data from Okta

{% hint style="info" %}

### Notice

Ingestion of logs and data requires a Cortex XDR Pro per GB license.
{% endhint %}

To receive logs and data from Okta, you must configure the Collection Integrations settings in Cortex XDR. After you set up data collection, Cortex XDR immediately begins receiving new logs and data from the source. The information from Okta is then searchable in XQL Search using the `okta_sso_raw` dataset. In addition, depending on the event type, data is normalized to either `xdr_data` or `saas_audit_logs` datasets.

You can collect all types of events from Okta. When setting up the Okta data collector in Cortex XDR , a field called **Okta Filter** is available to configure collection for events of your choosing. All events are collected by default unless you define an Okta API Filter expression for collecting the data, such as `filter=eventType eq “user.session.start”.\n`. For Okta information to be weaved into authentication stories, `“user.authentication.sso”` events must be collected.

Since the Okta API enforces concurrent rate limits, the Okta data collector is built with a mechanism to reduce the amount of requests whenever an error is received from the Okta API indicating that too many requests have already been sent. In addition, to ensure you are properly notified about this, an alert is displayed in the **Notification Area** and a record is added to the **Management Audit Logs**.

Before you begin configuring data collection from Okta, ensure your Okta user has administrator privileges with a role that can create API tokens, such as the read-only administrator, Super administrator, and Organization administrator. For more information, see the [Okta Administrators Documentation](https://help.okta.com/en-us/Content/Topics/Security/Administrators.htm?cshid=ext_Security_Administrators).

To configure the Okta collection in Cortex XDR:

1. Perform the following steps in your Okta application:
   1. Identify the domain name of your Okta service.

      From the Dashboard of your Okta console, on the top right corner, click the down arrow under your name, and copy your **Org URL**. The **Org URL** is listed under your email and record it for future reference as you'll need it when specifying your **OKTA DOMAIN** in Cortex XDR as explained below.

      For more information, see the [Okta Documentation](https://developer.okta.com/docs/guides/find-your-domain/findorg/).
   2. Obtain your authentication token in Okta.
      1. Select **Admin Console** → **Security** → **API** → **Tokens**, and click **Create token**.
      2. Set the following parameters for the token:
         * **What do you want your token to be named?**: Specify the name for your token, which is used for tracking API calls.
         * **API calls made with this token must originate from**: Select **Any IP**.
      3. Click **Create token**, and you may need to login to Okta again using your MFA administrator credentials.
      4. Your token is successfully created and you can now copy the **Token Value** and record it for future reference as you'll need it when specifying your **TOKEN** in Cortex XDR as explained in the following step. Once you close the dialog box by clicking **Ok, got it**, you won't be able to access the token again and will have to create a new one if you didn't record it.
2. Configure the Okta Collection Integrations settings in Cortex XDR
   1. Select **Settings** → **Configurations** → **Data Collection** → **Collection Integrations**.
   2. In the **Okta** configuration, click **Add Instance**.
   3. Integrate the Okta authentication service with Cortex XDR.
      1. Specify the **OKTA DOMAIN** (Org URL) that you identified on your Okta console as explained in the previous step above.
      2. Specify the **TOKEN** used to authenticate with Okta, which you recorded in Okta as explained in the previous step above.
      3. Specify the **Okta Filter** to configure collection for events of your choosing. **All events** are collected by default unless you define an Okta API Filter expression for collecting the data, such as `filter=eventType eq “user.session.start”.\n`. For Okta information to be weaved into authentication stories, `“user.authentication.sso”` events must be collected.
      4. **Test** the connection settings.
      5. If successful, **Enable** Okta log collection.

         Once events start to come in, a green check mark appears underneath the **Okta** configuration with the amount of data received.
   4. After Cortex XDR begins receiving information from the service, you can Create an XQL Query to search for specific data. When including authentication events, you can also Create an Authentication Query to search for specific authentication data.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-3.x/cortex-xdr-3.x-documentation/data-management/data-ingestion/external-data-ingestion/ingest-authentication-logs-and-data/ingest-logs-and-data-from-okta.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.