Overview

The Veza integration for Okta enables user provisioning and deprovisioning, with support for group membership management and attribute synchronization.

This document includes steps to enable the Okta integration for provisioning, along with supported actions and notes. See for more details.

1. You will need administrative access in Veza to configure the integration and grant API scopes in Okta.

2. Ensure you have an existing in Veza or add a new one for use with provisioning.

3. Verify your Okta integration has completed at least one successful extraction

To enable the integration:

1. In Veza, go to the Integrations overview.

2. Search for or create an Okta integration, then click its name to open the Integration details page.

3. Click Edit.

Configure the extraction schedule to ensure your Okta data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Okta in the Active Overrides section

To verify the health of the provisioning data source:

1. Open Lifecycle Management > Integrations (in the Products section of the navigation sidebar), or the main Integrations page (in the Featured section)

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Okta can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from Okta with changes propagated to connected systems.

Okta can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow:

The integration supports the following :

Primary action for user management (creating or updating users):

• Login ID cannot be changed after creation

• Email addresses must be unique

• Required attributes must be present (login, email, first_name, last_name)

The following attributes can be synchronized:

Both adding and removing memberships are supported. Group memberships are removed in deprovisioning.

• Add and remove group memberships

• Synchronize group assignments

• Track membership changes

When a user is deprovisioned:

• User account is disabled or suspended

• Group memberships are removed

• Attribute history is preserved for audit

• Account can be reactivated if needed

• Entity Types: Okta Groups

• Assignee Types: Okta Users

• Supports Relationship Removal: Yes

Within Okta, groups can be associated with:

• Application group assignments controlling SSO access

• Permissions to resources within specific applications

• Synchronized AWS SSO groups

• Role-based access controls within Okta

Resets passwords for Okta users by expiring their current password and generating a temporary password:

• Requires the login attribute as a unique identifier

• Non-idempotent action (each execution creates a new password reset event)

• Expires the user's current password immediately

Permanently removes a user from Okta:

• Entity Type: Okta User

• Action: User account is permanently deleted from Okta

• Removes All Relationships: Yes — all group memberships are removed automatically

Limitations:

• Permanent and cannot be undone

• Use DEPROVISION_IDENTITY instead when temporary removal or reactivation may be needed

Veza integrates with Okta to gather individual user metadata, applications, groups, and domains. After synchronizing with Okta, Veza shows the relationships connecting Okta identities and the external data sources and services they access (such as Snowflake databases, SQL tables, or AWS S3 buckets).

• You can use Okta properties such as country, department, or login date to filter queries and define access reviewers for Okta users

• If Veza does not detect an identity mapping from Okta to another integrated data source, you can define the relationships with

• If your organization uses in addition to the standard properties collected by Veza, you can enable them on the Veza configuration screen.

Veza can establish a connection to Okta using OAuth 2.0 application credentials or user API keys. OAuth is recommended to provide greater control over application permissions, but you can use API keys for testing or non-production environments.

Veza requires admin-level permissions in your Okta organization to gather user, group, application, and role metadata. Based on successful customer implementations, you have two authentication approaches:

Log in to Okta to create a new app integration, generate keys, and assign scopes and roles:

Choose one of the admin role options from the section above. If you encounter a permissions error during role assignment, navigate to Okta Settings > Features and enable the Assign admin roles to public client app option.

1. Go to Applications after logging into your Okta account. Record your Okta organization's URL, omitting https://

2. Create a new app:

   • Click on Create App Integration.

1. Assign scopes: In the Okta API Scopes section, grant the application scopes based on your use case:

   For basic integration (minimum required):

   • okta.users.read

   • okta.groups.read

1. On the Admin Roles tab, click Edit Assignments > Add Assignment. Assign your chosen admin role (custom admin role recommended, or read-only administrator) and save the changes.

   If you plan to use the integration for Lifecycle Management provisioning, an additional Group Membership Administrator role assignment is required to authorize group-membership write operations. See for the full configuration.

Authenticate with an admin user API token

Create a user for Veza and assign an administrator role:

1. Open Directory > People and click Add Person.

2. Enter user details for the profile (such as VezaIntegration). Click Save.

3. Open Security > Administrators and click Add Administrator.

Get an access token for the Okta user

1. Sign in to your Okta domain with the admin username and password.

2. Go to Security > API using the admin console menu. Open the Tokens tab.

3. Click Create Token.

For more information, see in the Okta documentation.

Go to the Veza Integrations page to enable the Okta integration:

1. Click Integrations in the navigation sidebar.

2. Click Add Integration > Okta.

3. Enter your organization's Okta Domain to authenticate with.

After creating the integration, verify that Veza can successfully connect to your Okta organization and discover entities:

1. Check Integration Status: On the Integrations page, locate your Okta integration and verify the status shows "Connected" or "Extracting". Initial extraction may take several minutes depending on your organization size.

2. Monitor Data Source Discovery: Click on your Okta integration to open the details page, then select the Data Sources tab to see all discovered Okta domains and applications.

3. Review Integration Events: Select the Events tab to view connection logs and verify there are no permission errors or authentication failures.

For troubleshooting integration issues, see the Active Jobs page under Integrations to monitor real-time extraction status and identify any errors requiring attention.

By default, Veza discovers all Okta domains and applications in the account. You can deselect the "Gather All Applications" option to only sync specific apps based on the settings.

Note: When adding application names to the allowlist or denylist fields, enclose app names containing spaces or special characters in double quotes. For example: "My Database (Production)", "Test Environment #1". App names without spaces or special characters do not require quotes.

Veza can parse Okta system logs to extract activity metadata. This enables two key capabilities:

• Incremental Extraction for the Okta integration: Enabling audit logs allows updates to Access Graph metadata only for entities that have changed since the last snapshot. This reduces the time needed to gather users, groups, apps, and roles during each sync. Administrators should enable this feature post-Okta integration setup to improve extraction speed and minimize traffic to Okta API endpoints.

• Support for , including generation of Over Provisioned Scores for Okta users.

• OAuth Token Activity Monitoring: Tracks OAuth credential usage including client secret reads and refresh token grants. This enables visibility into how applications and users interact with OAuth credentials, supporting Non-Human Identity (NHI) security monitoring.

To enable audit logs for an Okta integration:

1. Open the Integrations overview and locate the Okta integration.

2. Click Actions > Enable Audit Logs.

To disable activity monitoring and incremental extraction, toggle the option to Disable Audit Logs.

Your Okta organization might add additional user metadata with . To include these custom properties during discovery, specify the Name and data Type of each property to collect.

For example, if your organization used a custom attribute to track employee region, you can use this information for by adding the custom property to the Okta integration configuration.

1. On Edit Integration > Custom Properties tab, click Add Custom Property.

2. Enter the variable name region as the property name to collect.

3. Pick String as the property type.

The specified attributes will appear on Access Graph entities the next time Veza connects to the Okta domain.

The supported types are:

• String

• Number

• Boolean

• RFC339 Timestamp

Veza honors RFC339 timestamp formats, such as: 2006-01-02T15:04:05Z07:00, 2006-01-02T15:04:05.999999999Z07:00, 2006-01-02 15:04:05Z07:00, 2006-01-02 15:04:05, 2006-01-02, 2006-01-02T, 2006-01-02T15:04:05, 2006-01-02T15:04:05Z Time values in the format "18:47:12.019Z" (that do not contain dates) are only supported in strings.

Veza can automatically detect relationships for Okta and AWS, Snowflake, and other providers. However, some connections to standalone data sources need to be explicitly mapped.

• Administrators can disable default IdP User > Local User mapping by email when adding a custom mapping.

• Administrators can configure up to four property matchers for custom identity mapping based on possible combinations of user name and email. If any matcher is valid, Veza connects the IdP and local identities.

• When submitting authorization metadata for custom apps with the , local users, groups, roles, and permissions are mapped to Okta identities by login email and group name.

Use to manually create a connection to another provider. For example, employees might be able to access a standalone SQL database with their Okta credentials:

1. Open the Okta provider configuration menu (Configuration > Identity Providers > Add or Edit)

2. Click Identity Mapping Configurations

3. Pick the Destination Datasource Type. The mapping will apply to all resources of the chosen provider (such as SQL Server).

Veza gathers metadata and creates searchable Access Graph entities to represent:

• Okta Domains: Organizational domains configured in Okta

• Okta Users: Individual user accounts with profile attributes, status, and group memberships

• Okta Groups: User groups for managing access and permissions

OktaApp entities support .

The Is Active property for an Okta user is determined by their status in Okta. A user is considered Is Active: true if their status is one of the following:

• ACTIVE

• PASSWORD_RESET

• LOCKED_OUT

If a user's status is anything else (e.g., STAGED, DEPROVISIONED, SUSPENDED, DEACTIVATED), their Is Active status will be false. The raw status is available in the Status attribute for more granular filtering.

Okta API Token entities represent active API tokens in your Okta organization. These tokens are created by administrators to authenticate API calls to Okta services. Each API token entity includes the following attributes:

• Name: The descriptive name assigned to the API token

• Client Name: The client application name associated with the token (if applicable)

• User ID: The Okta user ID of the token owner

API tokens are connected to their owner via a "Has Access Credentials" relationship, allowing you to identify which users have administrative API access to your Okta organization.

Okta Application Client Secret entities represent OAuth 2.0 client secrets used by Okta applications for authentication. These secrets are critical credentials that allow applications to authenticate to Okta and other services. Each client secret entity includes the following attributes:

• Key ID (kid): Unique identifier for the secret

• Status: Current status of the secret (e.g., ACTIVE, INACTIVE)

• Last Updated: Timestamp when the secret was last modified

Okta Application Refresh Token entities represent OAuth 2.0 refresh tokens that provide persistent access to resources. These tokens allow applications and users to maintain access without re-authentication. Each refresh token entity includes the following attributes:

• Client ID: The OAuth client application identifier

• User ID: Associated user ID (if user-specific)

• Scope: List of OAuth scopes granted to the token

Okta Application Key Credential entities represent public key credentials (certificates) used by Okta applications for authentication and signing. These credentials enable secure, certificate-based authentication for applications. Each key credential entity includes the following attributes:

• Key ID (kid): Unique identifier for the credential

• Key Type: Type of cryptographic key (e.g., RSA, EC)

• Algorithm: Signing algorithm used (e.g., RS256, ES256)

When audit logs are enabled, Veza monitors OAuth credential usage events to provide visibility into how applications interact with OAuth tokens. The following events are tracked:

• Client Secret Reads: When an application's client secret is accessed (app.oauth2.client.read_client_secret)

• Refresh Token Grants: When OAuth refresh tokens are issued (app.oauth2.as.token.grant.refresh_token)

These events appear in Activity Monitoring and contribute to identifying OAuth credential usage patterns across your Okta environment. This supports Non-Human Identity (NHI) security by tracking programmatic access to OAuth credentials.

Extraction performance is directly tied to the Okta API rate limits configured for your tenant. Veza calls the /api/v1/apps* endpoint group — covering application listing, user and group assignments, and credential discovery — for every extraction cycle. When the remaining quota falls below a threshold, Veza backs off and waits for the reset window before continuing. In environments with large application catalogs and reduced rate limits, extraction cycles can take substantially longer to complete.

Configure the /api/v1/apps* rate limit to the maximum percentage your Okta environment permits. If that limit is insufficient for your catalog size, Okta provides a process to request a higher baseline. See in the Okta developer documentation.

If your Okta Multi-factor enrollment policies are such that traffic from Veza's Cloud IP Addresses is denied the ability to use a factor, Veza will not be able to detect user enrollment in that factor. As a result, the "MFA Active" property for Okta users will be "False," even if factors are enabled for the user. To prevent this, you can can:

• Configure an Okta Network Zone that allows optional MFA factors

• Use an Insight Point to connect to Okta from an IP address internal to your data center that does not have these restrictions

See below for more details and steps to enable:

Okta have the ability to not only set enrollment but also define usage. MFA enrollment policies work by evaluating from the highest priority to the lowest priority at the policy level (filtered by groups), and then at the rule level (filtered by and ).

This means that if there is not a policy rule that fits the incoming request, Okta will check the next policy that applies to the user until it finds one (Default Policy applies to everyone and Default Rule applies everywhere).

There are 2 options to allow Veza to fully collect MFA enrollment.

1. Configure a Network Zone specifically for the Veza IP Addresses and allow the factors as optional at the Policy level and deny the Enrollment at the Policy Rule Level:

   • Create an Okta Group to control scope during deployment.

   • Configure for under Gateway IPs.