canonical: https://jentic.com/apis/okta.com/okta

# Okta Admin Management API

Jentic publishes the only available OpenAPI specification for Okta Admin Management API, keeping it validated and agent-ready. Provides full administrative control over an Okta organization with 727 endpoints spanning user lifecycle management, application provisioning, group policies, authentication policies, and authorization server configuration. Supports both API token and OAuth 2.0 authentication with granular scopes for least-privilege access across tenant domains.

## For AI agents

Manage users, groups, applications, and authentication policies across an Okta organization. Provision identities, assign apps, configure MFA policies, and administer authorization servers.

## Scope

Does not handle authentication flows for end users, token issuance, or SSO login ceremonies - use for administrative management of the Okta organization only.

## Capabilities

- Provision and deactivate user accounts with profile attributes and credential settings
- Assign applications to users and groups with specific sign-on mode configurations
- Configure authentication policies with MFA requirements and device trust rules
- Define authorization server scopes, claims, and access policies for API protection
- Synchronize user groups from Active Directory and LDAP via agent pools
- Enroll and manage authenticator factors including TOTP, SMS, and push notifications
- Monitor system log events for security audit and compliance reporting

## Use cases

### AI Agent Identity Administration

AI agents perform identity administration tasks through Okta's Management API by searching Jentic for specific operations like user provisioning or group assignment. The agent loads the operation schema, supplies required fields (login, email, profile attributes), and executes directly against the Okta tenant. Handles user lifecycle from creation through deactivation across organizations with hundreds of thousands of identities.

Example prompt: Create a new user via POST /api/v1/users with profile containing firstName, lastName, email, and login, then activate the user and assign them to an application

### Application Provisioning and SSO Configuration

Configure single sign-on for applications by creating app instances with SAML 2.0 or OIDC settings, then assigning users and groups. The /api/v1/apps endpoint supports 20+ application templates including custom SAML and bookmark apps. Credential settings, attribute mappings, and provisioning features are configurable per assignment.

Example prompt: Create a SAML 2.0 application via POST /api/v1/apps with signOnMode 'SAML_2_0', configure the assertion consumer service URL, then assign a user group to the application

### Authentication Policy Management

Define and enforce authentication policies that control how users sign in, including MFA requirements, device trust conditions, and network zone restrictions. Policies are assigned to applications and evaluated in priority order. Supports progressive profiling, step-up authentication, and risk-based adaptive rules.

Example prompt: Create an authentication policy via POST /api/v1/policies with type 'ACCESS_POLICY', add a rule requiring MFA with possession factor, and assign it to a target application

### Security Audit and Compliance Monitoring

Query the Okta system log for security-relevant events including login failures, privilege escalations, policy changes, and suspicious activity patterns. The /api/v1/logs endpoint supports filtering by event type, actor, target, and time range. Results include geo-location, device context, and authentication details for forensic analysis.

Example prompt: Query /api/v1/logs with filter for event type 'user.session.start' with outcome 'FAILURE' over the last 7 days, then aggregate results by actor to identify brute-force patterns

### Authorization Server and API Access Control

Configure custom authorization servers that issue scoped access tokens for API protection. Define custom scopes, claims mapped from user profiles or groups, and access policies that control which clients receive which tokens. Supports token lifetime configuration and refresh token rotation policies.

Example prompt: Create a custom authorization server via POST /api/v1/authorizationServers, add a custom scope 'read:orders', define a claim mapping group membership, and create an access policy rule

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /api/v1/users | Create a new user with profile and credentials |
| GET | /api/v1/users | List all users with search and filter |
| POST | /api/v1/apps | Create a new application instance |
| PUT | /api/v1/apps/{appId}/users/{userId} | Assign a user to an application |
| GET | /api/v1/logs | Query the system log for events |
| POST | /api/v1/groups | Create a new user group |
| POST | /api/v1/authorizationServers | Create a custom authorization server |
| POST | /api/v1/policies | Create an authentication or authorization policy |

## Key resources

- **Users** — Full lifecycle management including creation, activation, suspension, password reset, and profile updates
- **Applications** — SSO application provisioning with SAML, OIDC, and SWA sign-on modes
- **Groups** — User grouping for application assignments, policy targeting, and directory sync
- **Authorization Servers** — Custom OAuth 2.0 servers with scopes, claims, policies, and token settings
- **Policies** — Authentication, sign-on, and password policies with priority-ordered rules
- **System Log** — Audit trail of all administrative and authentication events

## Why Jentic

- **Setup:** Wiring the Okta Admin Management API by hand means choosing between SSWS token and OAuth 2.0 auth, targeting your own Okta org domain, and navigating over 700 administrative endpoints across users, apps, groups, and policies yourself. Through Jentic you install once, import Okta from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** Okta puts resource ids in the URL path (for example /api/v1/apps/{appId}/users/{userId}), so a rule can pin your agent to one app's user assignments, and across the admin surface you limit it to the operations it needs, such as listing users or reading logs. You choose the operations it may call, so writes like creating a user or a policy are not included unless you add them.
- **Credential handling:** Your Okta SSWS token or OAuth client credentials are stored once, encrypted, by your own Jentic One instance and used to build the Authorization header at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'provision a new user in Okta', and Jentic returns the matching operation with its full input schema, including required profile fields, so the agent calls POST /api/v1/users without scanning over 700 endpoints.

## Related APIs

- **Auth0 Authentication API** — Authentication-focused API with passwordless, MFA, and token endpoints but less administrative breadth
- **FusionAuth API** — Self-hosted identity platform with similar user and application management without per-user pricing
- **JumpCloud API** — Unified directory platform combining identity, device, and access management
- **Snyk API** — Security vulnerability scanning and remediation for application dependencies and container images

## FAQ

### Why is there no official OpenAPI spec for Okta Admin Management API?

Okta does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Okta Admin Management API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Okta Admin Management API use?

The Okta Admin Management API supports two authentication methods: an SSWS API token passed in the Authorization header as 'SSWS {token}', or OAuth 2.0 access tokens using the authorization code flow with granular scopes like okta.users.manage. Through Jentic, credentials are stored in your Jentic One instance and agents receive properly formatted Authorization headers without handling raw tokens.

### Can I provision users and assign applications with the Okta Admin Management API?

Yes. POST /api/v1/users creates a user with profile attributes (firstName, lastName, email, login) and optional credentials. Then PUT /api/v1/apps/{appId}/users/{userId} assigns that user to an application with an optional credentials object and profile mapping. Through Jentic, search for 'create okta user' to load the full schema and execute.

### What are the rate limits for the Okta Admin Management API?

Okta enforces per-endpoint rate limits. The /api/v1/users endpoint allows 600 requests per minute for list operations and 100 per minute for create/update. /api/v1/logs allows 120 requests per minute. Rate limit headers (X-Rate-Limit-Limit, X-Rate-Limit-Remaining, X-Rate-Limit-Reset) are included in every response. Exceeding limits returns HTTP 429.

### How do I query security events through the Okta Admin Management API via Jentic?

Search Jentic for 'query okta system log' to find the GET /api/v1/logs operation. The schema accepts filter parameters using Okta Expression Language (e.g., eventType eq 'user.session.start' and outcome.result eq 'FAILURE'), plus since and until timestamps. Results include actor, target, client, and geographic context for each event.

### Can I configure custom authorization servers with the Okta Admin Management API?

Yes. POST /api/v1/authorizationServers creates a custom server with name, audiences, and description. Add scopes via POST /api/v1/authorizationServers/{authServerId}/scopes, define claims via the /claims endpoint, and set access policies via /policies. Each server issues tokens independently with its own signing keys and token lifetimes.

### Does the Okta Admin Management API support group-based application assignment?

Yes. PUT /api/v1/apps/{appId}/groups/{groupId} assigns all members of a group to an application in a single call. Group rules at POST /api/v1/groups/rules can automatically add users to groups based on profile attributes, enabling dynamic application access based on department, location, or role.

### Can I limit what my agent is allowed to do with the Okta Admin Management API?

Yes. Because you run Jentic One yourself, your own rules decide which of the 700-plus Okta operations and which stored credential the agent may use. Okta puts resource ids in the URL path, such as /api/v1/apps/{appId}/users/{userId}, so you can pin the agent to one application's user assignments or restrict it to read-only calls like listing users (GET /api/v1/users) or querying the system log (GET /api/v1/logs). Write operations such as creating a user (POST /api/v1/users) or an authentication policy (POST /api/v1/policies) are available to the agent only if you add them to its allowed set.