> For the complete documentation index, see [llms.txt](https://docs.euno.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.euno.ai/sources/identity-and-organization/okta-integration.md).

# Okta

## Overview

Euno integrates with Okta to observe users and groups from your identity and access management system. This integration enables you to track user accounts, groups, and group memberships in your data model, providing visibility into organizational structure and access patterns.

Euno's Okta integration supports auto-discovery of the following resources:

* Users (`user`)
* User groups (`user_group`)

For properties and relationships, see [Okta Integration Discovered Resources](/sources/identity-and-organization/okta-integration/okta-integration-discovered-resources.md).

## Requirements

To ingest metadata from Okta, you need:

* An Okta organization
* An Okta API token created by an **admin**. Only admins can create API tokens. The token inherits the current privileges of that admin account.

Euno only needs to list users, groups, and group members. Use a dedicated service account and follow [Least-privilege Okta API token](/sources/identity-and-organization/okta-integration/least-privilege-okta-api-token.md) so the token is not created by a Super Administrator unless you intend that.

## Setup Instructions

### Step 1: Create an Okta API Token

Create the token while signed in as the dedicated service account from [Least-privilege Okta API token](/sources/identity-and-organization/okta-integration/least-privilege-okta-api-token.md) (Read-only Administrator, or a custom view-only role after the token is minted).

1. Sign in to your [Okta Admin Console](https://admin.okta.com/) (or `https://<your-org>-admin.okta.com`).
2. Navigate to **Security** → **API** → **Tokens**.
3. Click **Create Token**.
4. Enter a name for the token (for example, `Euno` or `euno_app`). The name is only used for tracking API calls.
5. For **API calls made with this token must originate from**, either select **Any IP**, or select a network zone that contains all of Euno's IP addresses (see [Restricting the token to Euno's IP addresses](#restricting-the-token-to-eunos-ip-addresses) below).
6. Click **Create Token**.

{% hint style="warning" %}
Copy the token immediately. Okta does not show it again after you close the dialog.
{% endhint %}

#### Restricting the token to Euno's IP addresses

Euno calls the Okta API from Euno's cloud, not from your office network, so the token must be usable from every Euno egress address. Euno's public IP addresses are:

* `35.224.29.172`
* `44.218.99.77`
* `3.214.77.39`

If your security policy does not allow **Any IP**, create an Okta network zone that includes all of these addresses and select it when you create the token:

1. In the Admin Console, go to **Security** → **Networks**.
2. Click **Add zone** and choose **IP Zone**.
3. Give the zone a name (for example, `Euno`).
4. Under **Gateway IPs**, add each address above (or the same address with `/32`).
5. Save the zone.
6. Return to **Security** → **API** → **Tokens** and create the token as described above, selecting this zone instead of **Any IP**.

{% hint style="info" %}
Restricting the token to a network zone that does **not** include all of these addresses causes authentication failures on every source run. If Euno's egress addresses change, a zone-restricted token stops working until you add the new addresses to the zone, so choose **Any IP** if you prefer not to manage that.
{% endhint %}

### Step 2: Configure the Okta source in Euno

1. Go to the **Sources** page.
2. Click **Add New Source** and select **Okta**.
3. Fill in the configuration below.
4. Click **Save**.

Asterisk (\*) means a mandatory field.

| Configuration     | Description                                                                                                      |
| ----------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Name**\*        | A name for this Okta source (for example, `Okta - Production`).                                                  |
| **Okta Domain**\* | Your Okta organization domain, without `https://` (for example, `dev-12345.okta.com` or `yourcompany.okta.com`). |
| **API Token**\*   | The API token from Step 1. Stored as a secret.                                                                   |

### Step 3: Schedule

1. Toggle **Schedule** to activate updates.
2. Configure:
   1. **Weekly**: Select the days and times for updates.
   2. **Hourly**: Set the interval in hours.

### Step 4: Resource Cleanup

To keep your data relevant and free of outdated resources, Euno provides automatic **resource cleanup** options. These settings determine when a resource should be removed if it is no longer detected by a source. For a detailed explanation on Euno's cleanup strategies, see [Resource Sponsorship in Euno](/developer-reference/technical-concepts/resource-sponsorship-and-cleanup-in-euno.md).

* **Immediate Cleanup**: Remove resources not detected in the most recent successful source run. This is the default for Okta.
* **No Cleanup**: Keep all resources indefinitely, even if they are no longer detected.

## What Euno Discovers

### Users

Euno observes users from your Okta organization. For each user, Euno captures:

* The Okta primary **email**. Euno stores this value as both `name` and `email_address` and builds the resource URI from it.
* Display name (`label`)

Okta requires every user to have a login and a primary email. A username can be set to a value that is not an email, but the primary email is still required, and Euno uses that email.

### User Groups

Euno observes groups from your Okta organization. For each group, Euno captures:

* Group name
* Okta group ID (`native_id`)
* Creation timestamp
* Direct user memberships (`has member` / `has group`)

### Group Memberships

Euno observes **direct user memberships** only. Okta does not support nested groups, so a group is not a member of another group. Each Okta group is observed as its own `user_group`.

## Troubleshooting

### Authentication Errors

If you encounter authentication errors (401/403):

* Verify that the API token is correct and has not expired (unused tokens expire after 30 days)
* Confirm the service account that owns the token is still active and can list users, groups, and group members
* If you recently reduced that account to a custom view-only role, confirm the role includes **View users and their details** and **View groups**
* Check that **Okta Domain** matches your organization domain (no `https://`)
* Confirm the token is allowed from **Any IP**, or from a network zone that includes all of Euno's IP addresses (`35.224.29.172`, `44.218.99.77`, and `3.214.77.39`) (see [Restricting the token to Euno's IP addresses](#restricting-the-token-to-eunos-ip-addresses))

### Missing Users or Groups

If users or groups are not appearing in Euno:

* Verify that the token's admin can read the resources you expect to see
* Check the source run report for errors or warnings
* Ensure the resources exist in your Okta organization
* Search for a user by their primary email. Euno uses that email even when the Okta username is not an email address.

### Group Members Not Showing

If group members are not being observed:

* Confirm the admin who created the token can list group members
* Check that the groups have user members assigned in Okta
* Review the source run report for API errors when fetching group members


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.euno.ai/sources/identity-and-organization/okta-integration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.