Entrust Identity Verification for Okta: Technical Solution Overview

Audience

• Okta administrators configuring and enforcing Identity Verification (IDV) policy in the Okta Admin Console.
• Entrust IDV administrators configuring the integration in Workflow Studio.
• Security architects evaluating trust boundaries, data handling, and failure behavior before approving the Entrust IDV integration with Okta.

Overview

Assumptions: This overview assumes the customer is using Okta Identity Engine, has access to Okta account management policies, and has an Entrust IDV account provisioned for the target environment. Detailed administrator procedures, screenshots, and tenant-specific values are handled during implementation.

Entrust IDV integrates with Okta Identity Engine through Okta's supported IDV vendor framework. Okta administrators can require high-assurance IDV at sensitive moments in the workforce identity lifecycle, such as password recovery, account unlock, and authenticator enrollment or unenrollment. The process combines government-ID document verification with biometric matching and liveness checks and is configured through standard Okta policy controls. No custom code, inline hooks, or professional services are required.

Where Entrust fits

In the identity assurance model defined by the National Institute of Standards and Technology (NIST) in Special Publication 800-63, Entrust provides identity proofing: establishing who a person is through document verification, biometric matching, liveness checks, and fraud detection. This produces the Identity Assurance Level (IAL) signal. Okta remains the authority for authentication, federation, and access policy, using the identity assurance signal Entrust provides.

The sections that follow move from system responsibilities to verification flow, supported triggers, setup requirements, data exchange, and operational behavior. Read them in sequence if you are evaluating the integration end to end, or use the section headings to jump directly to the area you need to validate.

Architecture and Trust Boundaries

The deployment follows an Entrust-hosted, Okta-orchestrated model. Okta controls when verification is required and enforces the policy outcome; Entrust hosts the verification experience, performs identity proofing, and returns a verification outcome claim to Okta. The claim indicates whether the user was verified or not verified.

Okta-hosted components (customer-owned):

• Okta Identity Engine
• Okta account management and authentication policies
• Okta Admin Console (configuration and policy assignment)

Entrust-hosted components:

• Entrust IDV web application at verify.onfido.com (the user-facing verification experience)
• Entrust IDV backend services: document verification, biometric matching, and fraud controls including presentation attack detection and injection attack detection (detecting spoofed captures and manipulated camera feeds)
• OpenID Connect (OIDC) endpoints at https://api.onfido.com/okta/oidc (the machine-facing interface Okta communicates with)

Okta acts as the control plane for policy evaluation, user redirection, and enforcement. Entrust operates the verification services and retains custody of sensitive identity data collected during verification. Okta receives the verification outcome claim and configured attribute match results; it does not receive identity documents or biometric data. No shared administrative access exists between Entrust and the customer's Okta tenant.

How It Works

The trust boundary described above is reflected in the runtime flow: Okta initiates verification, Entrust performs the identity proofing steps, and Okta makes the final policy decision based on the verification outcome claim returned by Entrust.

The integration uses the OIDC authorization code flow with Pushed Authorization Requests (PAR, RFC 9126) and Proof Key for Code Exchange (PKCE, RFC 7636, S256 method), as defined by Okta's IDV vendor framework.

1. A user attempts an action governed by an Okta account management policy (for example, resetting a password or enrolling an authenticator).
2. Okta evaluates the policy and determines that IDV is required.
3. Okta sends a secure, server-to-server PAR to Entrust containing the user attributes to be matched (at minimum, first and last name).
4. Entrust establishes a unique verification session and returns a request_uri to Okta. Okta uses that URI to continue the authorization flow without exposing the full request through the user's browser.
5. Okta redirects the user's browser to the hosted Entrust verification experience at verify.onfido.com. We support both mobile and desktop experiences.
6. The user captures their government-issued identity document and completes biometric matching and liveness checks. Entrust can also apply additional verification and fraud signals as configured for the customer workflow:
   • Driver's License Data Verification: validates driver's license data against authoritative sources where supported, helping confirm that the license details are consistent with trusted records.
   • Device Intelligence: evaluates device, browser, network, and behavioral signals associated with the verification attempt to help identify suspicious or higher-risk activity.
   • Identity Enhanced: compares multiple identity signals in a consolidated assessment, giving Entrust additional context for detecting inconsistency, synthetic identity risk, or other fraud indicators.
7. Entrust evaluates the verification, including document authenticity, biometric matching, liveness, and fraud signals.
8. The user's browser is returned to Okta with an authorization code. Okta exchanges the code at Entrust's token endpoint and receives the verification outcome claim, which indicates whether the user was verified or not verified.
9. Okta evaluates the verification outcome claim and enforces the result: the protected action proceeds if the user was validated, or it is blocked and routed to the customer's defined remediation path if the user was not validated.
10. Every verification attempt is logged for audit in both Workflow Studio and the Okta System Log, so support teams can correlate a single verification across both platforms.

Each verification transaction is independent and stateless, so verification load scales with the high-risk events that trigger it rather than with total authentication volume.

Supported Use Cases and Triggers

Entrust supports all IDV triggers documented in Okta's account management policy framework:

Employee onboarding is enforced through the first authenticator enrollment during account activation: the new hire cannot complete activation until IDV succeeds.

Administrators choose which triggers require verification and which user populations are subject to those rules through Okta account management policies. Enforcement is selective and reversible; verification does not run on routine logins unless a policy requires it.

Prerequisites and Setup

Setup requires Okta Identity Engine and an Entrust IDV account with access to Workflow Studio. See the product guide for the full prerequisites list and the step-by-step Workflow Studio and Okta Admin Console configuration walkthrough. Workflow Studio generates only a Client ID and Client secret for the integration. The OIDC endpoints are static and already pre-configured in the Entrust IDV OIN tile; the required scopes are fixed by Okta's IDV vendor framework. Current values are published at Entrust's OIDC discovery document: https://api.onfido.com/okta/oidc/.well-known/openid-configuration.

Credentials are generated once and do not require ongoing Workflow Studio access at runtime. The customer owns and operates the Okta configuration end-to-end.

Custom IDV vendors cannot be used in Okta routing rules; routing behavior should be designed through the supported account management policy controls described in the product guide.

Data Exchanged Between Okta and Entrust

What Okta sends to Entrust:

• The user's first name and last name, mapped from Okta Universal Directory (sent by default)
• Fuzzy matching is available and configured per attribute during setup in the Document Report in Workflow Studio. When enabled, minor variations between the directory attribute and the verified document can still satisfy the match rule. If an attribute does not satisfy the configured match rule, the assurance level returns FAILED and the corresponding claim value is returned as null.

What Entrust returns to Okta:

• A verification outcome claim indicating whether the user was validated or not validated
• Per-attribute match confirmation. Entrust returns a match indicator rather than the underlying identifying data, so Okta learns that the name matched without receiving the document contents

What never leaves Entrust:

• Identity document images
• Biometric data and selfie captures
• Fraud and risk analysis detail

Entrust processes and temporarily holds the identity data collected during verification. Retention and deletion of that data are governed by the customer's contractual agreement with Entrust and their configured retention settings; Entrust does not retain it indefinitely. The integration does not change where identity data is processed or introduce new categories of data handling risk beyond a standard Entrust IDV deployment.

Failure Behavior, Reliability, and Audit

Fail-closed enforcement

See Deny-by-Default in the Use Case Implementation Guide for how the integration behaves when verification fails, times out, or the service is unreachable.

Entrust operates, monitors, and maintains the verification services centrally. Updates to verification logic, document coverage, and fraud detection are deployed by Entrust without customer redeployment or changes to the customer's Okta configuration.

Audit and observability

See Auditing and Observability in the Use Case Implementation Guide for the specific System Log event names, correlation properties, and how to use them for compliance reporting.

Regional Availability

Entrust's Okta integration is served through a single global endpoint set that is fronted from the EU by default. For most customers this is transparent, but organizations with strict regional data privacy requirements (for example, requiring that identity data never leaves the US) may need verification traffic to stay within a specific jurisdiction instead.

For these cases, customers can register a separate regional identity verification vendor entry in the Okta Admin Console using region-specific endpoint values (eu, ca, or us), so that verification traffic does not transit through another region. This regional configuration is a fallback for customers with strict data residency requirements; most organizations do not need it and can use the standard global endpoint set. See the regional routing and data residency section of the product guide for the endpoint values and setup steps.

Known Limitations

This integration does not currently include:

• Okta Classic Engine support
• Okta Privileged Access workflows
• Automated post-verification attribute updates in Okta Universal Directory
• Asynchronous or continuous risk signaling
• Consumer IDV use cases (offered separately by Entrust; this integration targets workforce scenarios)
• Use of custom IDV vendors in Okta routing rules

Frequently Asked Questions

Does the verification experience require a mobile device?

No. The Entrust verification experience supports both mobile and desktop browsers, with no application to install. Validate your organization's supported browser versions as part of rollout testing.

Does this require custom development or Okta Professional Services?

No. Setup is completed in the Okta Admin Console using values generated by Workflow Studio.

What happens if Entrust is unreachable during a password reset?

The reset is denied, and the user follows the customer's defined remediation path. Entrust unavailability never causes Okta to grant access.

Does Okta receive my employees' identity documents or biometric data?

No. Okta receives the verification outcome claim and configured attribute match confirmations; identity document images, selfie captures, and biometric data remain with Entrust.

Can we require verification for some users, or some actions, but not others?

Yes. Okta policy rules can apply verification requirements by group, user context, and action type.

Related guides

• Identity Verification for Okta: Product guide
• Identity Verification for Okta: Reference architecture
• Identity Verification for Okta: Use case implementation guide