> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Connecting Okta to Neo

> Create an API token in a client's Okta org and save it in Neo

You connect Okta once for each client that uses it, with two values from that client's Okta org: its address and an API token.

## 1. Create the API token in Okta

**1. Sign in as the admin Neo acts as**

An Okta API token acts with the admin roles of the account that creates it, and Okta's System Log shows that account on everything Neo does. Sign in to the client's Okta Admin Console with an admin account you keep for Neo. For onboarding, offboarding, resets and app assignments, that account needs the **Super Administrator** role, or both **Organization Administrator** (users, groups, resets) and **Application Administrator** (apps, app assignments and their licences). See Okta's [administrator role comparison](https://help.okta.com/en-us/Content/Topics/Security/administrators-admin-comparison.htm). A **Help Desk Administrator** can reset passwords and MFA and unlock users only.

**2. Create the token**

Go to **Security** → **API** → **Tokens**, click **Create token**, name it "Neo", and copy the token value. Okta shows it once.

**3. Allow Neo's addresses**

When you create the token, leave **API calls made with this token must originate from** set to any IP, or choose a network zone that includes [Neo's IP addresses](/integrations/ip-whitelisting).

## 2. Add the token in Neo

**1. Open Integrations**

In the Neo Dashboard, open [**Integrations** → **Okta**](https://dashboard.neoagent.io/integrations?open=okta), under Identity & Workspace.

**2. Pick the client**

In **Customer**, choose the client this Okta org belongs to. The client must be on your **Companies** tab. For a second client, click **Add customer**.

**3. Save the address and token**

Enter the org's address, like `https://contoso.okta.com` (the Admin Console address `https://contoso-admin.okta.com` works too), paste the token, and click **Save settings**. Neo checks both against Okta before saving: a wrong address, or a token that is mistyped, revoked or made in another org, is rejected straight away. Use the org's address on Okta's own domain (`okta.com`, `oktapreview.com`, `okta-emea.com`, `okta-gov.com`), not a custom sign-in domain.

> [!WARNING]
>
> Okta expires an API token that is not used for 30 days, and revokes it when its admin account is deactivated. When that happens, create a new token and save it here. Neo loses access to that client's Okta org until you do.

## 3. Turn Okta on per agent

**1. Open the agent's tools**

Open the agent in the Neo Dashboard, go to its **Tools & Settings** tab and click **Security**, or ask your Neo Support Agent to add Okta to it.

**2. Pick a preset**

Expand the **Okta** block and pick one of its **Presets**, or set each permission group by hand.

| Preset | What it does |
| - | - |
| **Read Only** | Reads users, groups, apps, policies and the System Log; changes nothing |
| **Helpdesk** | Onboarding, offboarding, password and MFA resets, group membership and app assignments, asking a technician before each change; settings stay read only |
| **IT Admin** | Every change on its own, except Admin Roles, Policies, Authenticators & Identity Providers, Hooks, Log Streams & API Access, and the [writes that always ask](/agents/tools/management/okta-api#writes-that-always-ask-a-technician), which ask a technician |
| **Full Automation** | Every supported call without approval, apart from the [writes that always ask](/agents/tools/management/okta-api#writes-that-always-ask-a-technician) |

An onboarding agent needs **Users & Lifecycle**, **Groups & Group Rules** and **App Assignments & Licences**. An offboarding agent needs **Users & Lifecycle**, **App Assignments & Licences** to read and remove the leaver's apps, and **Groups & Group Rules** at least Read Only to record their groups. A password or MFA reset needs **Passwords & MFA**.

## Clients whose users come from Active Directory

When a client's Okta imports its users from Active Directory, the directory owns each user's profile and password. The agent creates a new hire and resets a password in Active Directory with Neo's Active Directory tools, then works in Okta for groups Okta owns, app assignments and sessions. Connect the client's RMM so the agent can reach Active Directory.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.