Enable provisioning and deprovisioning for the Okta integration in Veza.
The Veza integration for Okta enables user provisioning and deprovisioning, with support for group membership management and attribute synchronization.
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
This document includes steps to enable the Okta integration for provisioning, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and grant API scopes in Okta.
Ensure you have an existing in Veza or add a new one for use with provisioning.
Verify your Okta integration has completed at least one successful extraction
The Okta integration will need the additional required API scopes:
To enable the integration:
In Veza, go to the Integrations overview.
Search for or create an Okta integration, then click its name to open the Integration details page.
Click Edit.
Check Enable usage for Provisioning.
Configure the extraction schedule to ensure your Okta data remains current:
Go to Veza Administration > System Settings
In the Integrations section, set your preferred Extraction Interval
Optionally, set a custom override for Okta in the Active overrides section
To verify the health of the provisioning data source:
Open Lifecycle Management > Integrations (in the Products section of the navigation sidebar), or the main Integrations page (in the Featured section)
Search for the integration and click the name to view details
In the Properties sidebar on the right (not the Properties tab), click the magnifying glass icon next to the Provisioning Support value
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
Returns an Okta-generated temporary password
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
okta.users.manage - For user lifecycle operations
okta.groups.manage - For group membership management
Assign an admin role on the Veza app in Okta that grants group-membership write permissions. OAuth scopes alone are not sufficient; Okta requires an admin role assignment on the service application to authorize writes against group resources.
In Okta, open the Veza app's Admin roles tab and click Add assignment:
Role: Group Membership Administrator
Resource scope: All Groups
Retain the existing Read-only Administrator role assignment. The two roles together provide the read permissions required for extraction and audit logs, and the write permissions required for Lifecycle Management group operations.
If your organization uses a custom admin role instead of standard administrator roles, see for the custom-role permissions that authorize Lifecycle Management actions.
Click Save Configuration.
Any password provided in the request is ignored; Okta always generates the temporary password
The user must sign in with the temporary password and will be prompted to set a new permanent password
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities, includes user logout support
✅
DELETE_IDENTITY
Permanently removes the user account from Okta
✅
CREATE_ENTITLEMENT
Creates entitlements such as Okta groups
✅
RESET_PASSWORD
Allows password reset operations for Okta users
✅
SOURCE_OF_IDENTITY
Okta can act as a source system for identity lifecycle policies
✅
login
Yes
String
Primary login identifier
Unique identifier
Yes
String
User's email address
Unique
first_name
Yes
String
Given name
last_name
Yes
String
Family name
display_name
No
String
User's display name
user_type
No
String
User type
department
No
String
Organizational department
title
No
String
Job title
manager
No
String
Manager's name
manager_id
No
String
Manager's identifier
employee_id
No
String
Employee identifier
division
No
String
Business division
organization
No
String
Organization name
cost_center
No
String
Cost center
country_code
No
String
Country code
second_email
No
String
Secondary email address
nickName
No
String
User's nickname
Yes
String
Group identifier
description
No
String
Group description
type
No
String
Group type
source
No
String
Group source
last_membership_updated_at
No
Timestamp
Last membership update time
Additional steps may be needed to fully gather enrolled MFA factors for Okta identities
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.
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.
Create a Veza MFA Enrollment Policy.
For Assigned Groups, enter the group created in step 1.
All authenticators are Optional (OIE requires 1 as Required).
Create a Veza Policy Rule:
IF User's IP is "in zone" (Add the Zone for Veza's Cloud IP Addresses)
AND User is accessing "Okta"
THEN Enrollment is "Allowed if required authenticators are missing".
Test the configuration by adding users to the group.
Veza should see everything and user experience should not be affected.
After testing, Remove the "Assigned" Group, and Apply the "Everyone" group.
Have Veza traffic to Okta run through an Insight Point installed in your data center. This asumes your data center IP Addresses do not have the same restrictions as Veza's Cloud IP Addresses.
Configuring the Veza integration for Okta.
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 custom identity mappings
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.
Go to Applications after logging into your Okta account. Record your Okta organization's URL, omitting https://
Create a new app:
Click on Create App Integration.
When configuring the Okta integration in Veza, click Generate & Download Key Pair. Veza downloads a .pem private key and a .json public key in JWK format, and auto-populates the Private Key ID field. In Okta, click Add under Public Keys and paste the contents of the downloaded .json file. Save your changes.
Click Add under Public Keys to generate a key pair in Okta. Copy the PEM value (starting with -----BEGIN PRIVATE KEY-----). Save this key and copy the Key ID (KID). Save your changes. You will upload this private key and enter the KID when configuring the integration in Veza.
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
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:
Open Directory > People and click Add Person.
Enter user details for the profile (such as VezaIntegration). Click Save.
Open Security > Administrators and click Add Administrator.
Get an access token for the Okta user
Sign in to your Okta domain with the admin username and password.
Go to Security > API using the admin console menu. Open the Tokens tab.
Click Create Token.
Give it a name and click Create Token.
For more information, see in the Okta documentation.
Go to the Veza Integrations page to enable the Okta integration:
Click Integrations in the navigation sidebar.
Click Add Integration > Okta.
Enter your organization's Okta Domain to authenticate with.
Pick the Credential Type: API token or OAuth.
After creating the integration, verify that Veza can successfully connect to your Okta organization and discover entities:
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.
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.
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: Enter application names in the allow and deny list fields without quotation marks. Names can include spaces and special characters. Matching applies to the full name and is case-sensitive, and entries can include
*wildcards. See .
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:
Open the Integrations overview and locate the Okta integration.
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.
On Edit Integration > Custom Properties tab, click Add Custom Property.
Enter the variable name region as the property name to collect.
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 detects many Okta relationships on its own, including Okta to AWS through the official application, and Okta to applications assigned through Okta single sign-on. Connections to standalone data sources need a mapping.
Applications submitted with the correlate to Okta identities through the identity values in the payload, which Veza compares against the Okta User Login, IdP Unique ID, and Email attributes. See .
To correlate on any other attribute, such as an employee ID or a custom property, add a property matcher.
Use to create a connection to another provider. For example, employees might access a standalone SQL database with their Okta credentials:
On the Integrations page, select your Okta integration and select Edit.
Open the Mapping Configuration step and select Add Mapping Configuration.
Pick the Destination Data Source Type. The mapping applies to all resources of the chosen provider, such as SQL Server.
Veza gathers metadata and creates searchable Access Graph entities of the following types:
Okta Domain: Organizational domains configured in Okta
Okta Identity Provider: External identity providers configured for inbound federation, with their type, issuer, and status
Okta User: Individual user accounts with profile attributes, status, and group memberships
Okta Group: 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
Created At: Timestamp when the token was created
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
Status: Current token status (e.g., ACTIVE, REVOKED)
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)
Usage: Key usage purpose (e.g., sig for signature)
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.
Read-only Administrator
Standard read-only admin permissions
Works with both authentication methods. Required for audit log features. Lifecycle Management provisioning requires an additional Group Membership Administrator assignment scoped to All Groups (see ).
✅ Yes
✅ Yes
Configure the Application:
Assign a descriptive name to your application.
In the app configuration section, edit the client credentials:
Copy the Client ID.
For Client Authentication, enable Public key/Private key.
In General Settings, ensure the option Require Demonstrating Proof of Possession (DPoP) is disabled.
Under Public Keys, add a key using one of the following methods:
okta.apps.read
okta.roles.read
okta.logs.read
okta.userTypes.read
okta.apiTokens.read
okta.authorizationServers.read
okta.appGrants.read
Additional scopes for Lifecycle Management:
okta.users.manage
okta.groups.manage
In the Grant Administrator Role To field, enter the name of the Veza user.
Assign your chosen admin role from the options detailed in the Admin Role Requirements section above.
Authorization Server Access: To collect Authorization Server entities (for OAuth/OIDC infrastructure visibility), API token users require custom admin role with the "View application grants" permission.
Lifecycle Management: If you plan to use the integration for Lifecycle Management provisioning, an additional Group Membership Administrator role assignment on the Veza user is required to authorize group-membership write operations. See Lifecycle Management prerequisites for the full configuration.
Save the changes.
Save the token value, which will only appear once.
For OAuth authentication, enter your client ID and private key ID. Upload the private key. Alternatively, click Generate & Download Certificate and Key Pair File to have Veza generate the key pair. Upload the downloaded public key to the Okta app (see step 3 in Authentication using OAuth 2.0 Credentials), and upload the private key here.
For API token authentication, enter the token generated for your Okta user.
(Optional) Enable Gather Credentials to discover OAuth tokens and application credentials. When enabled, Veza will extract:
Application Key Credentials
Client Secrets
Refresh Tokens
Note: This feature is disabled by default for security. Enable it only if you need visibility into Non-Human Identity (NHI) credentials for security assessments.
(Optional) Configure additional discovery options:
Gather deactivated users: Include users with deactivated status in discovery. Enable this to maintain visibility into formerly active accounts for audit purposes.
Extract users only: Skip discovery of groups and applications, extracting only user data. Use this option for identity-focused integrations or to reduce extraction time in large environments.
Gather Service App Only: Collect only Okta service applications and skip application user assignment collection. Use this option on large tenants to reduce extraction time and cost.
Domain allow list / Domain deny list: Control which Okta domains are discovered (comma-separated). Use allow lists to limit discovery to specific organizational units or deny lists to exclude test domains.
App allow list / App deny list: Control which applications are discovered (comma-separated). Enter names without quotation marks. Entries in the domain and app lists can include * wildcards, such as AWS*.
Click Next to configure optional identity mappings. These mappings correlate Okta users with local accounts in other systems when Veza cannot automatically detect a connection.
For enhanced security, you can store Okta credentials in an external secrets vault instead of directly in Veza. This keeps sensitive credentials in your private network. See Secrets Vaults for configuration details.
Click Next to specify any custom properties you want Veza to discover.
Click Create Integration to save the configuration.
To prevent large Okta environments from causing integration pipeline delays, Veza recommends enabling audit log extraction as described in the next section.
Test Data Discovery: Use the Query Builder to verify user data is being extracted correctly:
Go to Access Visibility > Query Builder
Select Okta User as the Entity Type
Run the query to confirm Okta users appear in results
Validate Permissions: If you encounter "Access Denied" errors in the Events tab, verify that:
The assigned admin role has all required permissions
The OAuth application scopes match your role permissions
The resource set configuration includes all necessary organizational units
OAA SSO last login enrichment (early access): Okta audit log data can populate sso_last_login_at on custom application (OAA) users, showing the last time each user accessed the application through Okta SSO. See Okta SSO last login enrichment.
Save the configuration.
Add a property matcher, and optionally a transformation. To compare only the username portion of an email address, enable Ignore Domain. To disregard punctuation in local usernames, enable Ignore Special.
Okta App: Applications integrated with Okta for SSO and access management
Okta App User: Individual user assignments to applications (Application Roles)
Okta App Group Assignment: Group-level assignments to applications
Okta Role: Administrator roles including standard roles (Super Admin, Read-only Admin, etc.) and custom admin roles
Okta Role Assignment: Assignments linking users or groups to administrator roles, including resource constraints for scoped access
Okta Group Rule: Automated rules that dynamically assign users to groups based on user attributes or conditions
Okta Constrained Resource: Individual resources (apps, groups, users) that custom admin roles are scoped to
Okta Constrained Resource Set: Collections of resources defining the scope of custom admin role permissions
Okta API Token: Active API tokens used for programmatic access to Okta
Okta Authorization Server: OAuth 2.0 and OIDC authorization servers managing token issuance and API access
Okta Auth Server Scope: OAuth scopes defining granular permissions for API access
Okta Access Policy: Authorization policies controlling client access to authorization servers
Okta Access Policy Rule: Rules within access policies defining specific access conditions
Okta Sign-On Policy: Global and application sign-on policies governing how users authenticate, with their type, priority, and status
Okta Sign-On Policy Rule: Rules within a sign-on policy, including factor requirements, session lifetime, risk score level, device trust mode, and the users, groups and network zones the rule includes or excludes
Okta Auth Server Key: Cryptographic keys used by authorization servers for token signing
Okta App Grant: OAuth application grants linking applications to authorization server scopes
Okta Application Client Secret: OAuth 2.0 client secrets for application authentication (when "Gather Credentials" is enabled)
Okta Application Refresh Token: OAuth 2.0 refresh tokens for persistent access (when "Gather Credentials" is enabled)
Okta Application Key Credential: Certificate-based credentials for application authentication (when "Gather Credentials" is enabled)
Updated At: Timestamp when the token was last modified
Expires At: Token expiration date (if set)
Network: Network restrictions configuration (JSON format)
Created At: Token creation timestamp
Last Updated: Last modification timestamp
Status: Current credential status (e.g., ACTIVE, EXPIRED)
Last Updated: Last modification timestamp
Custom Admin Role
Specific permissions only
Least privilege. Requires OAuth. Does not support audit logs (Okta platform limitation).
✅ Yes
Audit Log Limitation: Okta Custom Admin Roles cannot access System Logs, even with the okta.logs.read OAuth scope granted. This is an Okta platform limitation — only standard admin roles (such as Read-only Administrator) have System Log access.
If you need audit log features (incremental extraction, Activity Monitoring, OAuth token monitoring, or OAA SSO last login enrichment): use Read-only Administrator.
If you do not need audit logs and want least privilege access: use Custom Admin Role with OAuth authentication.
Prerequisite: Read-only Administrator role required. Okta Custom Admin Roles cannot access System Logs, even when the okta.logs.read OAuth scope is granted. This is an Okta platform limitation. If your integration uses a Custom Admin Role, you must switch to a Read-only Administrator role before enabling audit logs. See Admin Role Requirements for details.
❌ Not supported
"Manage group membership" — supports the Manage Relationships action (adding and removing users from groups)
Application Access: "View applications and their details" permission allows Veza to map application assignments and discover which users have access to specific applications in your environment.
Identity and Access Management: "View roles, resources, and admin assignments" permission enables discovery of administrative role assignments, providing visibility into privileged access within Okta.
API Token Management: "Manage API tokens" permission allows Veza to identify service accounts and programmatic access visibility.
Authorization Servers: "View application grants" permission enables discovery of OAuth/OIDC authorization servers, their policies, scopes, claims, and application grants for comprehensive Non-Human Identity (NHI) security coverage.
Restricted resource sets may limit Veza's ability to discover cross-departmental access relationships. Enable the full scope unless organizational security policies require limitations.
