Okta Expert

researched 2026-05-25· 35 sources · 10 concepts · skill okta-expert

High-signal Okta platform reference for authentication architecture, API

Okta Expert Reference

High-signal Okta platform reference for authentication architecture, API [source]
integration, org automation, security review, and 2025-2026 platform additions. [source]
Defer to the linked official Okta developer docs for exact API shapes and [source]
endpoint-level detail. [source]

Routing detail

SKIP: Okta security-management depth - tenant/admin-console hardening & breakglass, phishing-resistant MFA rollout (FastPass/passkeys), Zero Trust & device posture, ITDR/session-token defense, OIG certification-campaign design → security-review (references/okta-admin-hardening.md, okta-phishing-resistant-auth.md, okta-zero-trust-device.md, okta-itdr-session-security.md, okta-identity-governance.md); this skill keeps platform-level posture review (token choice, auth-server boundaries, rate limits). [source]
SKIP: agent identity, authorization & payments beyond the Okta platform - MCP authorization, cross-vendor non-human identity (Entra Agent ID, Auth0, Descope), agentic payments → agent-identity-authz-payments; this skill keeps the Okta-side surfaces (AI agent token exchange, ID-JAG, Okta for AI Agents). [source]
SKIP: MongoDB Atlas org SSO/SAML federation with Okta as the IdP (Federation Manager, group-to-role mapping, JIT/SCIM) → mongodb-atlas-expert (references/mongodb-atlas-federated-auth.md). [source]

When to use this skill

Planning Okta authentication architecture or reviewing an existing design [source]
Integrating Okta sign-in (redirect, embedded widget, Auth JS, SDKs) [source]
Automating Okta org administration (users, groups, apps, policies, hooks) [source]
Reviewing Okta security posture (token choice, auth-server boundaries, rate limits) [source]
Working with Identity Engine, OIG APIs, AI agent identity, or Terraform [source]

When NOT to use this skill

Non-Okta identity providers (Auth0, Azure AD/Entra, Cognito): use the relevant auth skill [source]
General OAuth 2.0/OIDC protocol theory not tied to Okta behavior [source]
Okta security-management depth, agent identity beyond Okta, or Atlas SSO federation: see Routing detail above [source]

Source scope

Treat the linked official Okta developer docs as the source of truth for exact [source]
API shapes, endpoint details, SDK usage, and product/version behavior. This [source]
skill provides the condensed expert map - not a replacement for the official docs. [source]

Okta platform, auth models, and engine concepts

Okta developer docs home: entry point for concepts, guides, APIs, and SDKs [source]
<https://developer.okta.com/docs/> [source]
Core Okta API: main API design rules, compatibility expectations, JSON and [source]
HTTP semantics, and management/auth surfaces [source]
<https://developer.okta.com/docs/reference/core-okta-api/> [source]
OAuth 2.0 and OpenID Connect overview: Okta’s standards-based auth model, [source]
grant concepts, and app-flow guidance [source]
<https://developer.okta.com/docs/concepts/oauth-openid/> [source]
Okta Identity Engine intro: the current Okta authentication pipeline and [source]
its policy-driven auth model [source]
<https://developer.okta.com/docs/concepts/oie-intro/> [source]
Redirect vs embedded authentication: Okta’s recommended deployment-model [source]
guidance and tradeoffs [source]
<https://developer.okta.com/docs/concepts/redirect-vs-embedded/> [source]
Authorization servers: org vs custom authorization servers and token [source]
<https://developer.okta.com/docs/concepts/auth-servers/> [source]

Okta API authentication and scopes

Management API authentication overview: scoped OAuth bearer tokens vs SSWS [source]
<https://developer.okta.com/docs/api/openapi/okta-management/guides/overview/> [source]
Implement OAuth for Okta: user/admin-scoped OAuth flow for Okta APIs [source]
<https://developer.okta.com/docs/guides/implement-oauth-for-okta/main/> [source]
Implement OAuth for Okta with a service app: machine-to-machine service [source]
app model, client credentials, JWKS, and admin-role assignment [source]
<https://developer.okta.com/docs/guides/implement-oauth-for-okta-serviceapp/main/> [source]
OAuth 2.0 scopes catalog: Okta admin-management scope inventory [source]
<https://developer.okta.com/docs/api/oauth2/> [source]

Sign-in surfaces and SDKs

Sign-In Widget concepts: Okta-hosted vs embedded widget, customization, [source]
and supported UX surface [source]
<https://developer.okta.com/docs/concepts/sign-in-widget/> [source]
SDK recommendations: preferred Okta SDKs and platform-specific guidance [source]
<https://developer.okta.com/code/> [source]
Authentication API: direct-authentication API for custom sign-in, [source]
recovery, MFA, and session bootstrap [source]
<https://developer.okta.com/docs/reference/api/authn/> [source]

Management APIs and objects

Users management API [source]
<https://developer.okta.com/docs/api/openapi/okta-management/management/tag/User/> [source]
Groups management API [source]
<https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Group/> [source]
Applications management API [source]
<https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Application/> [source]

Hooks, audit, and operations

Event hooks: async webhook-style event delivery from Okta [source]
<https://developer.okta.com/docs/concepts/event-hooks/> [source]
Inline hooks: synchronous extension points inside Okta process flows [source]
<https://developer.okta.com/docs/concepts/inline-hooks/> [source]
Hooks best practices: hook auth, IP allow-listing, response-time, and [source]
<https://developer.okta.com/docs/guides/hooks-best-practices/> [source]
System Log query guide: audit/event querying, filtering, correlation, and [source]
<https://developer.okta.com/docs/reference/system-log-query/> [source]
Authentication and management rate limits: high-signal rate-limit rules [source]
for auth and org-management workloads [source]
<https://developer.okta.com/docs/reference/rl-global-enduser/> [source]

Infrastructure as code and org automation

Terraform overview: provider model, state management, and drift warnings [source]
<https://developer.okta.com/docs/guides/terraform-overview/main/> [source]
Enable Terraform access: API service app, scopes, admin roles, and [source]
client-credentials setup for Terraform [source]
<https://developer.okta.com/docs/guides/terraform-enable-org-access/main/> [source]

Okta quick rules

Prefer redirect authentication and the Okta-hosted Sign-In Widget [source]
for most app sign-in flows. [source]
Use Identity Engine-aware approaches and SDKs by default. [source]
Prefer scoped OAuth 2.0 access tokens over SSWS API tokens for Okta [source]
management API access. [source]
Use the org authorization server when the token needs **Okta API [source]
scopes; use a custom authorization server** for your own APIs. [source]
Never assume Okta response property order or a fixed complete response [source]
schema; the docs explicitly allow additive response changes. [source]
Escape any Okta API values before rendering them into HTML; the Core API docs [source]
explicitly warn that JSON responses may contain user input. [source]
Treat Authentication API, Sign-In Widget/Auth JS, and OIDC/OAuth [source]
as different surfaces with different trust and UX tradeoffs. [source]
Model hooks as external integration boundaries: event hooks are async, [source]
inline hooks are synchronous and user-flow-blocking. [source]
Design for rate limits and 429 handling from the start. [source]
Avoid split-brain admin workflows: if Terraform owns an Okta object class, [source]
don’t also hand-edit the same objects in the Admin Console. [source]

What Okta expertise should mean

An Okta-focused assistant should be able to reason across: [source]
end-user authentication: redirect vs embedded, Identity Engine, Sign-In [source]
Widget, SDKs, auth policies, sessions, MFA/authenticators [source]
Okta admin automation: users, groups, apps, policies, hooks, System Log, [source]
scopes, service apps, and least-privilege roles [source]
integration methods: Admin Console, management APIs, OIDC/OAuth, [source]
Authentication API, hooks, SDKs, Terraform [source]
security posture: token choice, auth-server boundaries, rate limits, [source]
request validation, hook endpoint hardening, and audit/monitoring design [source]

Identity Engine first

Okta Identity Engine is the modern authentication pipeline and changes how [source]
sign-in experiences, policies, app intent links, and remediation work. [source]
Okta’s SDK recommendations assume Identity Engine for the recommended [source]
methods on the developer code page. [source]
Guidance that predates Identity Engine may still exist, so answers should [source]
call out when a flow is Classic or alternate rather than current [source]

Redirect vs embedded

Okta explicitly recommends redirect authentication for most integrations [source]
because Okta hosts and secures the sign-in surface. [source]
If embedded auth is required, Okta prefers direct authentication over [source]
older embedded options, and still recommends using Okta SDKs or supported [source]
widget surfaces rather than inventing a raw flow. [source]
The security, SSO, and maintenance tradeoffs differ materially between [source]
redirect and embedded models, so any recommendation should name the chosen [source]

Auth server boundaries

Every Okta org has an org authorization server. [source]
The org authorization server is for Okta APIs and Okta OIDC SSO and [source]
isn’t customizable for audience, claims, policies, or scopes. [source]
Access tokens from the org authorization server are for Okta, not for [source]
validation by your own APIs. [source]
Custom authorization servers exist to secure your own APIs and custom [source]
scopes/claims, but require the relevant Okta product support. [source]

Core API and compatibility standards

All Okta API requests must use HTTPS. [source]
Use Accept: application/json and Content-Type: application/json for JSON [source]
Okta’s compatibility model explicitly allows: [source]
new query parameters in future versions [source]
new response properties [source]
omission of null-valued properties [source]
arbitrary property order in request and response JSON [source]
Do not rely on undocumented endpoints; the Core API docs explicitly say [source]
undocumented endpoints are private and subject to change. [source]
Escape Okta response values before rendering into browser/HTML contexts. [source]
Use ISO 8601/RFC3339 date handling for Okta dates. [source]

Protocol choice

Okta identity solutions are built on OAuth 2.0 and OpenID Connect. [source]
Use OIDC when the app needs user authentication and identity claims. [source]
Use OAuth 2.0 when the app needs delegated or machine access to protected [source]

Token/auth method choice

For Okta management APIs, Okta recommends scoped OAuth 2.0 access tokens [source]
instead of SSWS API tokens. [source]
SSWS API tokens are broader and inherit the admin permissions of the creator; [source]
OAuth scopes give better granularity and shorter token lifetimes. [source]
For service apps, use the Client Credentials flow with **private/public [source]
key material** and explicit admin-role assignment. [source]

Authorization server choice

Only the org authorization server can mint access tokens containing Okta [source]
Use custom authorization servers when you need custom scopes, claims, or [source]
policies for your own APIs. [source]
Do not design your app to validate or depend on the internal content of org [source]
authorization server access tokens. [source]

Preferred sign-in approach

Okta-hosted redirect sign-in is the recommended default because Okta maintains [source]
the Sign-In Widget and its security posture. [source]
Okta-hosted sign-in reduces the app’s direct credential-handling exposure and [source]
makes policy changes effective without redeploying app code. [source]

When to use the Sign-In Widget

Use the Sign-In Widget when you want a complete, supported sign-in/sign-up [source]
UX with MFA, recovery, and branding support. [source]
The widget can be: [source]
Okta-hosted via redirect [source]
loaded from Okta CDN [source]
installed as an npm module [source]
Okta-hosted widget remains the recommended approach where possible. [source]

When to use the Authentication API

Use the Authentication API only when you genuinely need a **custom end-to-end [source]
sign-in experience** with direct control over auth flow details. [source]
The docs explicitly point to the Sign-In Widget as easier for basic use cases. [source]
Public apps using Authn are more aggressively rate-limited and must avoid [source]
exposing user metadata before primary authentication succeeds. [source]

SDK guidance

Use Okta’s recommended SDKs where they exist rather than reimplementing raw [source]
For SPAs, Okta recommends Auth JS and wrapper SDKs for React, Angular, [source]
For server-side apps, Okta recommends standard OIDC libraries plus the [source]
relevant Okta-supported platform guidance/samples. [source]

Major resource families

The high-signal management surface includes: [source]
users [source]
groups [source]
applications [source]
sessions [source]
policies [source]
factors/authenticators [source]
devices [source]
hooks [source]
system log [source]

Scope and permission mapping

Think in both OAuth scopes and admin roles. [source]
Scopes control what the token can call. [source]
Admin roles constrain what the app/admin identity is allowed to manage. [source]
For service apps and Terraform, Okta explicitly requires both API scopes and [source]
admin-role assignment for least privilege. [source]

JSON/HTTP semantics

Okta uses appropriate HTTP verbs where possible. [source]
PATCH support may use JSON Patch and/or JSON Merge Patch depending on [source]
Code that integrates with Okta should be tolerant of additive schema changes [source]
and missing null properties. [source]

Event hooks

Event hooks are asynchronous outbound HTTPS calls from Okta triggered by [source]
subscribed event types. [source]
They are for notification/triggering external processes, not modifying the [source]
originating Okta flow. [source]
They use the System Log event structure and can reduce reliance on System [source]
Okta limits orgs to 25 active verified event hooks at a time. [source]

Inline hooks

Inline hooks are synchronous outbound calls from Okta to your external [source]
The Okta process pauses until your service responds. [source]
Supported inline hooks include token, user import, SAML assertion, [source]
registration, password import, and telephony. [source]
Because they are user-flow-blocking, latency and reliability are part of [source]
product correctness, not just ops hygiene. [source]

Hook security and reliability defaults

Use HTTPS only. [source]
Authenticate every hook request. [source]
Prefer stronger auth choices such as OAuth 2.0 for inline hooks when [source]
Optionally IP allow-list Okta callers if the environment requires it. [source]
Respond quickly; inline hooks directly affect end-user latency. [source]
Treat event hooks as at-least-once async notifications and design [source]
receivers idempotently. [source]

System Log

The System Log API is near real-time, read-only access to org audit and [source]
Use it for: [source]
troubleshooting and incident investigation [source]
compliance and security review [source]
performance optimization [source]
rate-limit diagnosis [source]
Prefer scoped OAuth 2.0/OIDC access tokens for System Log API access. [source]
Querying uses parameters like time bounds, filters, keyword search, sort [source]
order, and cursor-based pagination. [source]

Rate limits

Okta enforces per-user, per-endpoint, and state-token-sensitive limits for [source]
Identity Engine requests are specifically limited per user and per state token [source]
in short time windows. [source]
Authentication API and token endpoints also have per-username protection [source]
limits for brute-force resistance. [source]
429 handling is required behavior, not an edge case. [source]

Terraform model

Use Terraform when you want reviewable, versioned, repeatable Okta org [source]
The Okta provider manages org objects via API calls and maintains desired [source]
state through Terraform state files. [source]
Okta recommends one configuration per Okta org to reduce conflicts. [source]
Store Terraform state remotely when possible for versioning, encryption, and [source]

Terraform security and ownership

Terraform should authenticate with an Okta API service app using Client [source]
Credentials plus key-based auth. [source]
Grant only the required Okta API scopes and admin roles. [source]
Okta explicitly recommends managing an object type with **either Terraform or [source]
the Admin Console**, not both, to avoid synchronization issues. [source]

High-value method inventory

This is the condensed method map. Use the linked sources for exhaustive syntax [source]
and endpoint-level detail. [source]

Practical defaults for future Okta coding/review tasks

Start by classifying the task as end-user auth, org management, [source]
automation, audit/monitoring, or hook extension. [source]
Prefer redirect auth unless the product requirements clearly require [source]
Prefer Okta SDKs / Sign-In Widget over raw Authentication API work for [source]
mainstream sign-in flows. [source]
Prefer scoped OAuth over SSWS for Okta management API access. [source]
For automation, model both scope requirements and **admin-role [source]
For security review, examine auth-server choice, token type, **hook [source]
endpoint hardening, HTML escaping, and 429/backoff behavior**. [source]
For Terraform review, check ownership boundaries, state handling, [source]
least privilege, and rate-limit exposure. [source]

2025-2026 platform additions (refresh May 2026)

The sections below cover significant Okta platform changes released in 2025 and [source]
through May 2026 that are not reflected in the original skill content above. [source]
Treat these as additive material to the existing guidance. [source]

AI agent identity and token exchange

Okta now supports an AI agent token exchange flow built on the standard [source]
OAuth 2.0 Token Exchange grant type (RFC 8693). [source]
The flow lets an AI agent receive an ID token from a user's web-app session, [source]
exchange it at the org authorization server for an **Identity Assertion JWT [source]
(ID-JAG)**, and then present the ID-JAG to a custom authorization server to [source]
obtain a scoped access token for downstream resource access. [source]
Supported downstream resource types: authorization servers (via ID-JAG), [source]
secrets (vaulted in Okta Privileged Access), service accounts (static [source]
credentials in Universal Directory), and resource servers (third-party tokens [source]
requiring user consent). [source]
Use when securing agentic AI applications that act on behalf of authenticated [source]
users, including MCP-based tool servers. [source]
Guide: <https://developer.okta.com/docs/guides/ai-agent-token-exchange/-/main/> [source]
#### Okta for AI Agents (GA April 30, 2026) [source]
Okta for AI Agents is the full product surface for discovering, onboarding, [source]
protecting, and governing AI agent identities within an Okta org. [source]
Discovery and registration: discover agents (known and unknown) in the [source]
environment and register them in a single directory with assigned human owners. [source]
Access control: control the connections agents rely on (MCPs, APIs), [source]
centrally enforce access policies, and vault credentials to prevent lateral [source]
Governance and audit: govern agent access across its lifecycle; a kill [source]
switch prevents new token requests when an agent behaves unexpectedly. Agent [source]
activity (tool calls, authorization decisions, access attempts) flows to the [source]
System Log and can be forwarded to SIEM. [source]
Certification workflows: agents can be brought into standard OIG access [source]
certification workflows with automated reviews, human-owner assignment, and [source]
Product page: <https://www.okta.com/products/govern-ai-agent-identity/> [source]
Admin guide: <https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agents-home.htm> [source]

DPoP (Demonstration of Proof-of-Possession)

Okta added DPoP support for OAuth applications and authorization servers. [source]
DPoP binds access and refresh tokens to a client-held private key, making [source]
tokens sender-constrained and detectable if leaked or replayed. [source]
DPoP satisfies sender-constraining requirements of FAPI 2.0, the security [source]
framework for high-security financial and sensitive-data applications. [source]
Enable DPoP on the authorization server and configure clients to include the [source]
DPoP proof header in token requests. [source]
Blog: <https://www.okta.com/blog/product-innovation/a-leap-forward-in-token-security-okta-adds-support-for-dpop/> [source]

Anything-as-a-Source (XaaS)

Anything-as-a-Source lets organizations connect any custom identity source [source]
(HR apps, custom databases, third-party systems) to Okta's Universal Directory. [source]
The Identity Sources API supports individual and bulk operations on users, [source]
groups, and group memberships. [source]
A custom client drives synchronization between the external HR source and [source]
API reference: <https://developer.okta.com/docs/reference/api/xaas/> [source]
Build guide: <https://developer.okta.com/docs/guides/anything-as-a-source/> [source]

Unified claims generation

A new streamlined interface for managing claims (OIDC) and **attribute [source]
statements (SAML)** across Okta-protected custom app integrations. [source]
New claim types beyond user profile and groups: entitlements (requires [source]
OIG), device.profile, session.id, and session.amr. [source]
Claims are now configured on the Sign On tab of the app page using Okta [source]
Expression Language for OIE (EL for OIE). [source]
Guide: <https://developer.okta.com/docs/guides/federated-claims/main/> [source]

Enhanced Disaster Recovery

Enhanced DR gives admins self-service control over business continuity [source]
through dedicated APIs and the Okta Disaster Recovery Admin portal. [source]
Admins can initiate failover, test failover procedures, and automate [source]
restoration without waiting on Okta support. [source]
The APIs enable real-time monitoring-triggered failover automation to minimize [source]
API reference: <https://developer.okta.com/docs/api/openapi/okta-management/management/tags/disasterrecovery/disasterrecovery> [source]

Okta Identity Governance (OIG) APIs

OIG now has a full developer API surface for entitlements, **access [source]
requests, access certifications, campaigns, and reports**. [source]
Admins can assign owners to resources (apps, groups, entitlements) and [source]
auto-assign reviewers for access certifications scoped to those owners. [source]
The Entitlement Settings API lets admins opt in/out of entitlement [source]
management per resource. [source]
The Principal Entitlements API provides user entitlement history for audit [source]
OIG resources can now be managed via Terraform. [source]
API reference: <https://developer.okta.com/docs/api/iga> [source]

Realms

Realms allow management and delegation of distinct user populations within [source]
The Realms Management API provides programmatic control over realm creation, [source]
membership, and administration. [source]
Use Realms when a single org must serve multiple distinct tenants or [source]
organizational units with delegated admin boundaries. [source]

Policy and device management updates

Authentication policies have been renamed. The term now refers to a group [source]
of policies: app sign-in policies (formerly authentication policies), the [source]
Okta account management policy, and the session protection policy. [source]
The Policies API supports a new CLIENT_POLICY type to enforce or defer app [source]
updates across device platforms. [source]
Dynamic OS version compliance auto-updates device assurance policies with [source]
the latest OS versions and patches. [source]
The /api/v1/users/{userId}/risk PUT endpoint now accepts an optional [source]
riskReason field for custom risk-level annotations. [source]

Network zone per-client allowlists

You can now specify an allowlist or denylist network zone for each client to [source]
enhance token endpoint security. [source]

Org2Org OIDC sign-on mode

The Org2Org app now supports an OIDC sign-on mode using the Okta [source]
Integration IdP, reducing complexity over legacy SAML-based Org2Org [source]

Telephony provider simplification

Okta now supports connecting your own telephony provider (Twilio, Telesign) [source]
using a simplified setup that does not require a telephony inline hook. [source]

Policy Insights Dashboard

The Policy Insights Dashboard gives admins a clear view of a policy's [source]
impact on the org: successful sign-ins, access denials, authenticator [source]
enrollments, sign-in time trends, phishing-resistant authentication [source]
prevalence, rule match frequency, and successful sign-in percentages. [source]
Useful for tuning app sign-in policies without guessing at real-world impact. [source]

Intelligent Threat Protection

New Intelligent Threat Protection detection settings let admins define [source]
which session context changes (IP, device, location) trigger policy [source]
reevaluations mid-session. [source]
Complements existing session management and continuous access evaluation. [source]

Self-service registration planning guide

A new guide explains the self-service registration (SSR) flow, its default [source]
state, and three ways to customize and configure it. [source]
Guide: <https://developer.okta.com/docs/guides/oie-embedded-common-org-setup/main/> [source]

OIN submission changes

The ability to submit API service integrations through OIN Manager has been [source]
removed. Use the OIN Wizard instead for all new OIN submissions. [source]

Workday entitlement management (Preview, May 2026)

Admins can now manage entitlements for Workday app instances on Okta, [source]
enabling discovery and governance of user-based security groups for automated [source]
access requests and certifications. [source]

Classic Engine migration status

Okta provides a self-service upgrade path from Classic Engine to Identity [source]
Engine; most upgrades complete in minutes with no downtime. [source]
Okta Mobile reached End of Support on November 1, 2025, and End of Life [source]
Classic Engine documentation is now archived under the “Classic Engine” label. [source]
New development and features target Identity Engine exclusively. [source]
Migration guide: <https://developer.okta.com/docs/guides/oie-upgrade-overview/main/> [source]

Updated quick rules (additive)

When building AI agent integrations, use the AI agent token exchange [source]
flow rather than sharing long-lived tokens or static API keys with agents. [source]
For full lifecycle governance, use Okta for AI Agents (GA April 2026). [source]
Enable DPoP for high-security or FAPI-2.0-regulated applications. [source]
For custom identity sourcing, use the Anything-as-a-Source (XaaS) [source]
Identity Sources API rather than building ad hoc sync pipelines. [source]
When working with entitlements or access governance, use the OIG APIs [source]
for programmatic control of certifications and access requests. [source]
Be aware that “authentication policy” now refers to a group of policies; [source]
use the specific sub-policy names to avoid ambiguity. [source]
Use the Policy Insights Dashboard to measure real-world impact before [source]
tightening app sign-in policies. [source]
For high-availability requirements, verify whether Enhanced DR is enabled [source]
and whether failover automation is wired into the org's incident-response [source]

Known ambiguities and guardrails

“All Okta methods” is too large for a single static file. This document is the [source]
condensed expert map, not a replacement for the official API and guide pages. [source]
Okta guidance can differ between Identity Engine and older Classic [source]
flows; answers should call that out explicitly when relevant. [source]
Product availability and behavior can differ by org edition, **licensed [source]
features, and authorization-server type**. [source]
Management API schemas are intentionally forward-compatible; code should not [source]
fail on additive response changes. [source]
The 2025-2026 additions section reflects features announced through May [source]
2026 release notes. Okta ships monthly; check the official release notes for [source]
anything newer: <https://developer.okta.com/docs/release-notes/>. [source]
Some features in the additions section (Enhanced DR, Workday entitlements) may [source]
still be in Early Access (EA) or Preview and require feature flags or [source]
SKU entitlement. Always confirm GA status before recommending for production. [source]

Children

Okta Authentication Flows (frontier)
Okta API and SDK (frontier)
Okta Operating Model (frontier)
Identity and Access Management (frontier)

Frontier under this node: Identity and Access Management, Okta API and SDK, Okta Authentication Flows, Okta Operating Model

← the whole tree · 3D view· how to read this page