Reference · built on requestConnectorIdentity, IT & observability

Okta

Users, groups, apps, sessions, factors, and System Log events from an Okta org through the Core Okta API and Event Hooks.

Request accessPricing ↗

About

Okta is a workforce identity service that holds your users, groups, app assignments, MFA factors, sessions, and policies. The Core Okta API sits at https://{yourOktaDomain}/api/v1 and covers the Users, Groups, Apps, Sessions, Policy, User Factors, Devices, and System Log APIs. Event Hooks push a subset of System Log event types to an HTTPS endpoint you own.

Through Fibric, an operator watches Event Hook deliveries and the System Log, reads the user with its groups and app assignments, and proposes a suspension, a group change, or a session clear. You approve each one; the receipt names the user, the call, and the way back.

This is a reference listing. It documents what Fibric would read from Okta and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Users through the Users API, with lifecycle status STAGED, PROVISIONED, ACTIVE, RECOVERY, LOCKED_OUT, PASSWORD_EXPIRED, SUSPENDED, or DEPROVISIONED
  • Groups of type OKTA_GROUP, APP_GROUP, or BUILT_IN through the Groups API, with member users and assigned applications
  • Applications and their user and group assignments through the Apps API
  • MFA enrollments through the User Factors API and device records through the Devices API
  • System Log events through GET /api/v1/logs, with eventType, actor, target, outcome, and published, filtered by since, until, filter, or q
  • Event Hook deliveries as HTTPS POSTs to your endpoint, with nearby events batched in the data.events array

Proposed actions

  • Target capability: propose Suspend a user, Unsuspend a user, or Deactivate a user through the Users API
  • Target capability: propose Assign a user to a group or Unassign a user from a group through the Groups API
  • Target capability: propose Clear user sessions, Reset password, Expire password, or Reset factors for one user
  • Target capability: propose an Event Hook for the event types you choose, answering the one-time verification challenge on your endpoint

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Sweep access on the day someone leaves

    When HR marks a leaver, the operator reads the user's groups and app assignments and proposes Deactivate a user plus Clear user sessions. One approval, one receipt.

    With Offboarding Sweep

  • Find accounts nobody has used

    System Log events show which users have not signed in. The operator lists ACTIVE users with no recent sign-in and proposes suspensions for review.

    With Stale Accounts

  • Close MFA gaps

    The User Factors API shows who has no enrolled factor. The operator groups them by app assignment and drafts the reset or the enrollment nudge for approval.

    With MFA Gaps

  • Run a quarterly access review

    Groups, members, and assigned applications are pulled once. Reviewers see each user's access in one place and approve the Unassign calls the operator proposes.

    With Access Review

Requirements

  • An Okta org and a Super Admin to grant Okta API Scopes to the app on its Okta API Scopes tab
  • An admin role assigned to the OAuth 2.0 service app, which constrains it to that role's permissions and resources
  • A public and private key pair registered as a JWKS for private_key_jwt client authentication
  • A public HTTPS endpoint that answers the x-okta-verification-challenge and returns 200 or 204 within three seconds
Authentication
An OAuth 2.0 API Services app using the Client Credentials grant with private_key_jwt and Okta API scopes such as okta.users.read and okta.groups.manage; an SSWS API token is the older alternative.

Limits

  • Rate limits are bucket based per org and per client app; a bucket over quota returns 429 until it resets, usually every 60 seconds
  • System Log data older than 90 days is not returned, and a query times out after 30 seconds
  • At most 25 active event hooks per org, 300 event types per hook, and 400,000 applicable events per org in 24 hours
  • Access tokens last one hour; an event hook is retried once on a 5xx response and not at all on a 4xx

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Okta ↗

Questions and answers

How does Okta deliver events?
Two ways. Event Hooks POST JSON to an HTTPS endpoint you own, after a one-time verification challenge, and batch nearby events in data.events. The System Log API at GET /api/v1/logs supports polling requests with sortOrder=ASCENDING and bounded requests with since and until.
Which auth model does Okta expect for a server-side integration?
An API Services app using the Client Credentials grant. private_key_jwt is the only supported client authentication method for OAuth service apps that request Okta scopes. Only a Super Admin can grant scopes, tokens last one hour, and Okta says to assign admin roles to every service app.
How far back does the System Log go?
The System Log API does not return data older than 90 days, and the default page size is 100 events. Bounded requests are ordered by the published field; polling requests are ordered by persistence time and can arrive out of order.
Ask about Okta

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Okta through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy