> ## 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.

# Okta API

> Onboard and offboard users in your clients' Okta orgs, reset passwords and MFA, assign apps and the licences they provision, and read sign-on policies and the System Log

The common uses are staff onboarding and offboarding, and sign-in support: after the agent creates a new hire's Microsoft 365 account, it creates their Okta user, adds their groups and assigns their apps; when someone leaves, it signs them out everywhere and deactivates them; when someone is locked out or has lost their phone, it reads the System Log, then unlocks them or resets their MFA.

> [!NOTE]
>
> Automatically enabled when you configure Okta permissions in your agent workflow. Okta is connected per client: the agent names the client company on each call, and Neo uses that company's Okta org and token. It reaches only companies on your Companies tab.

## What it does

* Find users, create and activate them, update their profile, and suspend, unsuspend, unlock, deactivate and delete them
* Sign a user out of every session and revoke their app tokens
* Send a password reset, expire a password, give a temporary password, and reset or remove MFA factors
* Send an Okta Verify push to check a caller before a reset
* Add and remove group members, and manage groups, group owners and group rules
* Assign and remove apps for users and groups, with the app profile that carries a licence, such as Microsoft 365
* Read and change apps and their SSO settings, admin roles, sign-on and password policies, network zones, identity providers, devices and org settings
* Read the System Log

The agent reaches every operation of Okta's Management API, apart from a few it refuses with a reason: revoking an API token (Okta does not say which one Neo itself uses), publishing a signed security event, completing an app's provisioning sign-in (its code comes from an admin's browser), and Okta's disaster recovery API, which Okta serves on its own host to OAuth service apps only.

## Credentials in answers

When a call issues a credential for a person (an activation link, a password reset link, a temporary password or a Temporary Access Code), or makes a new secret that Okta shows only once (an app's new client secret, a new OAuth client or API service, a child org's token), the agent receives it sealed: it can pass it to the person the ticket names, and the run's stored steps never show it. A script in the agent's sandbox cannot make such a call: Neo refuses it before it reaches Okta, so the script uses the agent's tool or lets Okta email the link. Any other secret in Okta's answers, such as an app's client secret, is removed for every caller. When the agent updates a whole record it read, such as an app's SSO settings, Neo puts the removed secret back, or leaves it out where Okta keeps it, so the update does not change it. After an update to an app, Neo also checks that the app's client secret is still active, and tells the technician at once if it is not.

## Permission groups

| Group | Access levels | Covers |
| - | - | - |
| Users & Lifecycle | Disabled, Read Only, Read / Write | Users, their lifecycle (activate, deactivate, suspend, unlock, delete), sessions, app grants and refresh tokens, manager links and risk |
| Passwords & MFA | Disabled, Read Only, Read / Write | Password resets and expiry, temporary passwords, MFA factors and authenticator enrollments, recovery questions, hardware token seeds |
| Groups & Group Rules | Disabled, Read Only, Read / Write | Groups, members, owners and group rules |
| App Assignments & Licences | Disabled, Read Only, Read / Write | Who each app is assigned to, as a user or through a group, and each assignment's app profile, such as Microsoft 365 licences |
| Apps & SSO Settings | Disabled, Read Only, Read / Write | Apps, SSO settings, signing keys and certificates, client secrets, provisioning connections, group push, profile mappings, app user schemas |
| Admin Roles | Disabled, Read Only, Read / Write | Admin role assignments of users, groups and OAuth clients, custom roles, resource sets, privileged-access service accounts |
| Policies, Authenticators & Identity Providers | Disabled, Read Only, Read / Write | Sign-on, password, MFA enrollment and app sign-in policies, authenticators, network zones, behaviours, ThreatInsight, device assurance, identity providers, authorization servers, realms |
| Devices | Disabled, Read Only, Read / Write | Devices registered with Okta Verify and FastPass, and device integrations |
| System Log | Disabled, Read Only | Sign-ins, MFA challenges, lockouts, admin changes and provisioning events |
| Org, Branding & Directory Sources | Disabled, Read Only, Read / Write | Org settings and contacts, branding, domains, email and SMS templates, features, rate limits, user and group schemas, directory agents, identity sources, child orgs |
| Hooks, Log Streams & API Access | Disabled, Read Only, Read / Write | Event and inline hooks, log streams, API service integrations, API tokens, OAuth clients |

## Writes that always ask a technician

These ask for approval under every profile, whatever the group's own setting. A delete is never one of them: it follows the group, as any delete does, apart from revoking an API token, which Neo refuses.

* Every write to hooks, log streams, API service integrations, API tokens and OAuth clients (their admin roles included), because each sends the org's data to an outside address or changes a credential that reaches the org. Deleting follows the group, as any delete does, and so does deactivating a hook or a log stream. Neo never revokes the API token it calls with
* Every change to the credentials of an app, an identity provider or an authorization server (client secrets, keys, JWKs and certificate signing requests), because a system outside Okta signs in or checks signatures with each one
* Any other write outside a user's own record (their profile, password and MFA) whose body sets a secret, password, token or private key, or carries credential settings, such as an app's signing key or client secret in a full update, an identity provider's client secret, or an SMTP server's password
* Issuing a Temporary Access Code, which signs a user in once without MFA
* Creating a child org, and any change to Okta Support's access to the org

## Access profiles

| Profile | What runs on its own | What asks a technician |
| - | - | - |
| **Read Only** | Every read | No write is allowed |
| **Helpdesk** | Every read | Every change to users, passwords and MFA, groups and app assignments; apps, roles, policies and settings are read only |
| **IT Admin** | Every read, and every write except those to the right | Every write to Admin Roles, to Policies, Authenticators & Identity Providers, and to Hooks, Log Streams & API Access, and the writes that always ask |
| **Full Automation** | Every read, and every write except those to the right | The writes that always ask |


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