Okta is an identity and access management platform that helps organizations manage how users, devices, and applications authenticate and gain access to resources. It enables businesses to centralize user directories, enforce access policies, and monitor security activity across their applications.
Hevo uses the Okta Management API to replicate the users, groups, applications, devices, policies, System Log events, and other data of your Okta organization to the Destination of your choice. To ingest data, you must provide Hevo with the subdomain and domain of your Okta organization and an API token.
Supported Features
| Feature Name | Supported |
|---|---|
| Capture deletes | Yes, for all objects except System Log |
| History mode | No |
| Custom data (user-configured tables & fields) | Yes, for the custom profile attributes of users |
| Data blocking (skip objects and fields) | Yes |
| Resync (objects and Pipelines) | Yes |
| API configurable | Yes |
Prerequisites
-
An active Okta organization exists from which data is to be ingested.
-
You can log in to the Okta Admin Console as an administrator who can create API tokens. An API token has the permissions of the administrator who creates it, so create the token as a Super Administrator for Hevo to read all the objects. If the token cannot read an object, Hevo fails only that object and ingests the other objects.
-
The subdomain and domain of your Okta organization are available.
-
An API token is available to provide Hevo access to your Okta data.
Find your Okta Subdomain and Domain
The subdomain and domain are parts of the URL of your Okta organization. For example, if you log in to Okta at acme.okta.com, the subdomain is acme and the domain is okta.com. If the URL of your Admin Console contains -admin, such as acme-admin.okta.com, the subdomain is the part before -admin, that is, acme. Okta organizations use domains such as okta.com, oktapreview.com, and okta-emea.com.
Obtain the API Token
Hevo uses an API token to authenticate with your Okta organization. Okta recommends that you create the token from a dedicated service account, so that the permissions of the token do not change when an administrator’s role changes. Read Manage Okta API tokens.
Perform the following steps to obtain the API token:
-
Log in to your Okta Admin Console as an administrator.
-
In the left navigation pane, click Security, and then click API.
-
On the API page, click the Tokens tab, and then click Create token.
-
In the Create token dialog, specify the following, and then click Create token:
-
What do you want your token to be named?: A name for the token. For example, Hevo.
-
API calls made with this token must originate from: The network from which Okta accepts the API calls made with this token. Select Any IP. If you restrict the token to network zones, the zones must include the IP addresses of Hevo for your region.
Okta may ask you to verify your identity again before it creates the token.
-
-
Click the copy icon to copy the Token Value, and save it securely like any other password. Then, click OK, got it.
Note: Okta displays the token value only once.
Okta revokes an API token that is not used for 30 days, and when the administrator who created it is deactivated. If the API token is revoked, Hevo cannot read your Okta data, and the jobs of the Pipeline fail. To resume data replication, modify the Source configuration in the Pipeline with a new API token.
Configure Okta as a Source in your Pipeline
Perform the following steps to configure your Okta Source:
-
Click Pipelines in the Navigation Bar.
-
Click + Create Pipeline in the Pipelines List View.
-
On the Select Source Type page, select Okta.
-
On the Select Destination Type page, select the type of Destination you want to use.
-
In the Configure Source screen, specify the following:
-
Source Name: A unique name for your Source, not exceeding 255 characters. For example, Okta Source.
-
In the Connect to Okta section, specify the following:
-
-
Click Test & Continue to test the connection to your Okta Source. Once the test is successful, you can proceed to set up your Destination.
Data Replication
Hevo replicates data for all the objects selected on the Configure Objects page during Pipeline creation. By default, all supported objects and their available fields are selected. However, you can modify this selection while creating or editing the Pipeline. Selecting a parent object automatically includes its child objects. The Data Model lists the child objects of each parent object.
In the first run of the Pipeline, Hevo ingests all the data available for the selected objects in your Okta organization. For the System Log object, Hevo ingests the events of the last 90 days, which is how long Okta retains them. In the subsequent runs, as per the sync frequency, Hevo ingests data as follows:
| Ingestion | Objects |
|---|---|
| New and updated records, based on the time each record was last updated in Okta | Device, Groups, and Users |
| New events, based on the time each event was published | System Log |
| All the records, in each run | All the other parent objects, such as Application, Group Rule, Identity Provider, Network Zone, and Policy |
Hevo ingests the child objects of a parent object along with it. When Hevo ingests a parent record, it replaces the child records of that parent in the Destination.
Okta limits the number of API requests that an organization can make to each endpoint per minute. The limits depend on your Okta subscription, and the API token shares them with the other integrations of your organization. Read Rate limits. If Okta returns a rate limit error, Hevo waits and retries the request. If the limit is still exceeded, the object fails in that run, and Hevo ingests it again in the next run. To understand how Hevo handles such scenarios, read Handling Rate Limit Exceptions.
Pipelines with this Source support only the Merge load mode.
Schema and Primary Keys
Hevo uses the following schema to upload the records in the Destination. For a detailed view of the objects, fields, and relationships, click the ERD.
Data Model
The following is the list of tables (objects) that are created at the Destination when you run the Pipeline:
| Object | Description |
|---|---|
| API Token Metadata | Contains the details of the API tokens of your Okta organization, such as the token name, the user who created it, the creation and expiry times, and the network that the token is restricted to. Hevo does not ingest the token values. |
| Application | Contains the applications integrated with your Okta organization, including the name, label, status, sign-on mode, and settings. This object has the following child objects: - Application Client Credentials Link: The client credential links of an application. - Application Feature: The features enabled for an application. - Application Group: The groups assigned to an application. - Application Link: The resource links of an application. - Application Logo Link: The links to the logos of an application. - Application Sign On ACS Endpoint: The Assertion Consumer Service (ACS) endpoints of the SAML sign-on of an application. - Application Sign On Attribute Statement: The SAML attribute statements of an application. - Application Sign On Inline Hook: The inline hooks of the sign-on of an application. - Application User: The users assigned to an application, with the assignment scope and status. - Group Push Mapping: The mappings that push Okta groups to an application. - OAuth Client Grant Type: The OAuth grant types allowed for an application. - OAuth Client Post Logout Redirect URI: The post-logout redirect URIs of an OAuth application. - OAuth Client Redirect URI: The redirect URIs of an OAuth application. - OAuth Client Response Type: The OAuth response types allowed for an application. |
| Custom Role | Contains the custom administrator roles of your Okta organization. This object has the following child object: - Custom Role Permission: The permissions granted by a custom role. |
| Device | Contains the devices registered with your Okta organization, such as the platform, status, and registration time. This object has the following child object: - Device User: The users of a device. |
| Group Rule | Contains the group rules that assign users to groups based on conditions. This object has the following child objects: - Assign User To Group ID: The groups to which a group rule assigns users. - Group Excluded From Rule: The groups excluded from a group rule. - User Excluded From Rule: The users excluded from a group rule. |
| Groups | Contains the groups of your Okta organization, including the name, description, type, and the time the group or its membership was last updated. This object has the following child objects: - Group Logo Link: The links to the logos of a group. - Group Member: The users who are members of a group. - Group Role: The administrator roles assigned to a group. |
| Identity Provider | Contains the external identity providers (IdPs) federated with your Okta organization, including the name, type, status, and protocol settings. This object has the following child object: - Identity Provider Protocol Scope: The protocol scopes of an identity provider. |
| Network Zone | Contains the network zones of your Okta organization, including the name, type, status, and usage. This object has the following child objects: - Network Zone Gateway: The gateway IP addresses of a network zone. - Network Zone Proxy: The proxy IP addresses of a network zone. |
| Policy | Contains the policies of your Okta organization, such as sign-on, password, and authenticator enrollment policies, including the name, type, status, and priority. This object has the following child objects: - Policy Rule: The rules of a policy, including the conditions and actions. - Policy Rule Condition Excluded User: The users excluded from the conditions of a policy rule. |
| Profile Mapping | Contains the mappings of profile attributes between Okta and applications or identity providers. This object has the following child object: - Profile Mapping Property: The attribute mappings of a profile mapping. |
| Realm | Contains the realms of your Okta organization. Hevo ingests this object only if the Realms feature is enabled for your organization. |
| Realm Assignment | Contains the realm assignments that determine the realm of users. Hevo ingests this object only if the Realms feature is enabled for your organization. |
| Resource Set | Contains the resource sets that group resources for administrator role assignments. This object has the following child object: - Resource: The resources of a resource set. |
| System Log | Contains the System Log events of your Okta organization, such as the event type, actor, outcome, and the time the event was published. This object has the following child objects: - System Log Request: The IP chain of the request of an event. - System Log Target: The targets of an event. |
| User Type | Contains the user types of your Okta organization. |
| Users | Contains the users of your Okta organization, including their profile, status, and the times of their last login, last update, and last status change. This object has the following child objects: - User Authenticator Enrollment: The authenticators enrolled by a user. - User Credentials Email: The email addresses of the credentials of a user. - User Custom Profile: The custom profile attributes of a user, as name and value pairs. - User Enrolled Factor: The multifactor authentication factors enrolled by a user. - User Role: The administrator roles assigned to a user. |
Additional Information
Read the detailed Hevo documentation for the following related topics:
Handling of Deletes
Hevo marks a record as deleted by setting the value of the metadata column __hevo__marked_deleted to True. Hevo captures deletes as follows:
-
For the objects whose records Hevo ingests in full in each run, Hevo compares the records fetched from Okta with those in the Destination table. Records that are no longer returned by Okta are marked as deleted in the Destination.
-
For the Device, Groups, and Users objects, Hevo does not capture deletes in the runs that ingest new and updated records. Records deleted in Okta are marked as deleted only when Hevo ingests all the records of these objects, which happens in the first run of the Pipeline and when you resync the object. A deactivated user is not deleted; Okta returns it with the status DEPROVISIONED until it is deleted.
-
For the System Log object, Okta never changes or deletes an event, so Hevo does not mark any events as deleted.
-
For child objects, when Hevo ingests a parent record, it replaces the child records of that parent in the Destination. Child records removed from the parent record in Okta are removed from the Destination table.
Source Considerations
-
The objects that Hevo can read depend on the role of the administrator who created the API token. If the token cannot read an object, the object fails to load, and Hevo continues to ingest the other objects.
-
Okta retains System Log events for 90 days. If the Pipeline is paused for more than 90 days, the events published during that time are not available to Hevo.