Okta API

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.

​

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

​

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