Okta

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).

Native Identity Mapping: If you have a Google Workspace application configured in Okta, Veza automatically creates identity relationships to Google Workspace users and groups. Custom identity mapping is only needed for other integrations. See Custom Identity Mappings for details.

• 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 custom attributes in addition to the standard properties collected by Veza, you can enable them on the Veza configuration screen.

Integrating with Okta

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.

Overview Video - Okta Integration

Integrating Okta with Veza

Admin Role Requirements

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:

Role Type	Permission Scope	Implementation Notes	OAuth Support	API Token Support
Preferred: Custom Admin Role	Specific permissions only	Recommended for security compliance. Requires OAuth authentication.	✅ Yes	❌ Not supported
Option 2: Read-only Administrator	Standard read-only admin permissions	Works with both authentication methods	✅ Yes	✅ Yes

Custom admin roles provide the exact permissions required by Veza while maintaining least privilege access principles. This approach addresses security policies that restrict broad administrative privileges for third-party integrations.

Creating a custom admin role (Preferred)

Prerequisites:

• Okta organization with custom role feature enabled

• Current Okta user has Super Administrator rights (Okta platform requirement for creating custom roles)

• OAuth 2.0 application creation permissions

Required Permissions:

The following permissions are required for Veza integration:

• User Management: "Manage users" and "View users and their details" permissions allow Veza to discover user profiles, status, and group memberships. The manage permission enables access to user lifecycle events and attribute changes.

• Group Management: "View groups and their details" permission enables discovery of group structures and memberships. For organizations using Lifecycle Management, additional "Manage groups" permission supports automated provisioning workflows.

• 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.

Implementation Steps

To create a custom admin role, navigate to Security > Administrators > Roles in your Okta console and select Create Custom Role. Configure the role with the specific permissions required for the integration. Then, create a Resource Set that defines the scope of access for users, groups, applications, and Identity and Access Management resources.

The resource set configuration determines which organizational units the integration can access. For complete visibility, select "All users", "All groups", and "All applications", though you can restrict access to specific organizational units if required by your security policies.

Restricted resource sets may limit Veza's ability to discover cross-departmental access relationships. Enable the full scope unless organizational security policies require limitations.

Next, assign this custom role to your OAuth application during the integration setup process described in the Authentication sections below.

Example Custom Role and Resource Set Configuration

The User permissions section enables "Manage users" (for Lifecycle Management) and "View users and their details" (for gathering identity metadata). These allow Veza to access user profiles, group memberships, and lifecycle events.

User permissions configuration

For Group access, select "View groups and their details". The API Tokens section requires "Manage API tokens" to discover programmatic access patterns. Note that this provides read access to token metadata, not the actual token values.

Group and API token permissions configuration

The Application Permissions must include "View applications and their details" to map application assignments and user access patterns across your Okta environment.

Application permissions configuration

The Resource Set defines the scope of access for your custom role. This example shows a configuration named "Scoped" that includes all users, groups, applications, and Identity and Access Management resources. You can adjust these settings to match your organizational requirements.

Resource set configuration

After creating your custom admin role and resource set:

1. Save the role configuration in Okta

2. Continue to the Authentication using OAuth 2.0 Credentials section below to create your OAuth application

3. Assign this custom role to the OAuth application during step 5 of the OAuth setup

4. Complete the Veza integration configuration to connect using OAuth credentials

OAuth Authentication Required: Custom admin roles are only supported with OAuth Application Registration. Organizations using API token authentication must use the Read-only Administrator role.

Authentication using OAuth 2.0 Credentials

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 Admin Role Requirements 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.

   • Choose API Services as the integration type.

3. 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 and copy the PEM value (starting with -----BEGIN PRIVATE KEY-----). Save this key and copy the Key ID (KID). Save your changes.

     • Convert the PEM private key to an RSA private key using OpenSSL: Run openssl rsa -in ~/okta_generated.key -out okta_updated.key -traditional in your terminal.

4. 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

   • 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

Custom Role Alignment: If using a custom admin role, these OAuth scopes should align with the UI permissions configured in your role.

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.

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.

4. In the Grant Administrator Role To field, enter the name of the Veza user.

5. 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.

6. Save the changes.

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.

4. Give it a name and click Create Token.

5. Save the token value, which will only appear once.

For more information, see Create an API Token in the Okta documentation.

Configure the Veza integration for Okta

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

1. Click Integrations on the main navigation.

2. Click Add Integration > Okta.

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

4. Pick the Credential Type: API token or OAuth.

5. For OAuth authentication, enter your client ID and private key ID. Upload the RSA private key.

6. For API token authentication, enter the token generated for your Okta user.

7. (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.

8. (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.

   • 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). Enclose app names containing spaces or special characters in double quotes: "My App (Production)", "Test-App #1".

9. 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.

10. Click Next to specify any custom properties you want Veza to discover.

11. Click Create Integration to save the configuration.

12. To prevent large Okta environments from causing integration pipeline delays, Veza recommends enabling audit log extraction as described in the next section.

Verify Integration Setup

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.

4. 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

5. 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

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 allowlist 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.

Enable Audit Logs for Okta

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 Authorization 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 Activity Monitoring, including generation of Over Provisioned Scores for Okta users.

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.

Okta Custom Properties

Your Okta organization might add additional user metadata with Custom Attributes. 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 attribute filters 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.

4. Save the configuration.

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

The supported types are:

• String

• Number

• Boolean

• RFC339 Timestamp

• String List

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.

Okta custom identity mappings

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 Open Authorization API, local users, groups, roles, and permissions are mapped to Okta identities by login email and group name.

• Veza identifies Okta-AWS relationships based on the official AWS Account Federation app

Use Custom Identity Mappings 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).

4. Pick an optional transformation. By default, Veza will link identities based on email addresses (username@domain). To match only the username, use Ignore Domain. You can also ignore special characters in local usernames.

Notes and supported entities

Veza gathers metadata and creates searchable Authorization 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

• Okta Apps: Applications integrated with Okta for SSO and access management

• Okta App Users: Individual user assignments to applications (Application Roles)

• Okta App Group Assignments: Group-level assignments to applications

• Okta Roles: Administrator roles including standard roles (Super Admin, Read-only Admin, etc.) and custom admin roles

• Okta Role Assignments: Assignments linking users or groups to administrator roles, including resource constraints for scoped access

• Okta Group Rules: Automated rules that dynamically assign users to groups based on user attributes or conditions

• Okta Constrained Resources: Individual resources (apps, groups, users) that custom admin roles are scoped to

• Okta Constrained Resource Sets: Collections of resources defining the scope of custom admin role permissions

• Okta API Tokens: Active API tokens used for programmatic access to Okta

• Okta Authorization Servers: OAuth 2.0 and OIDC authorization servers managing token issuance and API access

• Okta Auth Server Scopes: OAuth scopes defining granular permissions for API access

• Okta Access Policies: Authorization policies controlling client access to authorization servers

• Okta Access Policy Rules: Rules within access policies defining specific access conditions

• Okta Auth Server Keys: Cryptographic keys used by authorization servers for token signing

• Okta App Grants: OAuth application grants linking applications to authorization server scopes

• Okta Application Client Secrets: OAuth 2.0 client secrets for application authentication (when "Gather Credentials" is enabled)

• Okta Application Refresh Tokens: OAuth 2.0 refresh tokens for persistent access (when "Gather Credentials" is enabled)

• Okta Application Key Credentials: Certificate-based credentials for application authentication (when "Gather Credentials" is enabled)

Okta User Active Status

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 Tokens

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

• Updated At: Timestamp when the token was last modified

• Expires At: Token expiration date (if set)

• Network: Network restrictions configuration (JSON format)

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 Secrets

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

• Expires At: Secret expiration date (if set)

Okta Application Refresh Tokens

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)

• Created At: Token creation timestamp

• Expires At: Token expiration date (if set)

• Last Updated: Last modification timestamp

Okta Application Key Credentials

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)

• Status: Current credential status (e.g., ACTIVE, EXPIRED)

• Expires At: Credential expiration date

• Last Updated: Last modification timestamp