Configure Persona for the Okta Account Management Policy

What is Okta workforce authentication?

Okta is used by companies of all sizes as a workforce authentication solution. The cloud-based Identity and Access Management (IAM) platform is designed to securely manage and streamline access for employees, contractors, and partners to enterprise applications, systems, and resources that need to be kept secure.

How Persona identity verification supports Okta workforce authentication

With the rise of social engineering and deepfake attacks, protecting a distributed and remote workforce is increasingly difficult. Persona adds a crucial layer of security by automatically verifying employees’ identities at sensitive moments throughout the employee lifecycle, such as new employee onboarding, account recovery, and the editing of sensitive information.

For businesses already using Okta, Persona is listed in the Okta Integration Network (OIN) as the Persona IDV integration, so it’s easily integrated, offers an added component of security to access controls, and helps keep employees from being blocked.

How to set up Persona Authentications for Okta workforce authentication

As part of this solution, you will need to configure Persona Authentications with OpenID Connect. Additionally, you will need to configure Verified Claims in order to work with Okta BYO IDV.

Capturing Okta user profile attributes you don’t intend to verify

Because Okta expects every value sent via PAR to be verified by Persona, PAR and Verified Claims should only be used to send attributes you intend to verify. For example, if you want to persist the user’s email address, don’t send it as a Verified Claim unless you actually intend to verify it (see Email (2FA) Verification).

Instead, use Persona’s Okta Marketplace integration in a Workflow to look up the employee’s user profile directly from Okta (the Retrieve a user action). Okta passes the employee’s Okta ID as the login_hint query parameter when it launches the Persona flow; read it off the Account for use in the Retrieve a user action. If you’re deferring account creation, add a query parameter-to-Inquiry-field mapping instead, to write login_hint into an Inquiry field you can access later.

How to set up Persona as your Identity Provider in Okta

To learn more about the Okta Account Management Policy, see the Okta documentation here. Please note, identity verification is only available for Okta Identity Engine (not Okta Classic) tenants, and requires MFA/AMFA features.

Configuring the policy

Under Security > Authentication Policies, click on your Okta Account Management Policy. Click on Add Rule and configure to your specifications (we recommend restricting this rule to a test group first). Under Identity Verification Service, select the appropriate Persona Identity Provider.

Updating your Password Policy

Edit your Password Policy rules to use the OAMP to determine the authenticators a user is prompted for.

Testing the policy

One of the easiest ways to test the integration is to go to the End User settings in Okta and attempt to change a security method. This triggers the Account Management policy and will bring the user through the Persona flow.

How the integration between Persona and Okta works

1. Upon the Authentication Policy rule trigger, the integration will create an OIDC authentication for the employee with:
   1. The client ID and secret provided in the BYO IDV configuration.
   2. The employee’s Okta ID as the Persona account’s reference-id (which will serve as the account identifier for Persona).
   3. The employee’s first and last name from the Okta Universal Directory, as Inquiry fields.
   4. A redirect URL (to get back to Okta). If you are using domain allowlisting, you will need to add your Okta tenant’s domain (e.g. persona.okta.com), or inquiry creations will be rejected.
2. The employee will be instructed to go through the Persona inquiry — a button in the Okta flow will bring them to a hosted Persona Inquiry page.
3. Once the employee has completed the inquiry, they will be redirected back to an Okta webpage.
4. If the authentication passes (all verifications have passed), the employee will be allowed to continue. Otherwise (at least one verification has failed), the user will be prevented from continuing.

Note that employees will have a limited period of time to complete identity verification. If they take more than ten minutes to verify, they may encounter an error and could potentially need to re-start the verification flow.

Understanding and making changes to your Inquiry template

Your template comes pre-configured via our standard recommendations for the Know Your Employee verification experience, but is customizable in the following ways:

• Updating inquiry configurations and verification checks to require more or less friction for your employee (for example: requiring that the barcode of any drivers’ licenses be captured and scanned, or only allowing IDs from certain countries). Please refer to the Google spreadsheet given to your team for an in-depth explanation of Persona’s verification checks and other available configurations.
• Configuring the colors of your template to match your company’s brand.
• Adding any custom text to help your employees through the process.

Troubleshooting

Persona is not opening when triggering OAMP

If the Persona flow does not open at all, an error is likely happening when Okta is attempting to create the Persona Authentication.

In the Okta Admin dashboard, navigate to Reports > System Log and filter for outcome.result eq "DENY". These logs may include error messages or other context to help identify the issue. For example, ReasonForFailure may say PAR response doesn't have an HTTP 201 status code, instead received a status code of 400. This implies a misconfiguration; for example, this error can happen if the Verified Claims configured in the Persona Authentication Template do not match the user attribute mapping configured in the Okta Identity Provider.

The Persona Inquiry flow is unexpectedly failing

Find the Authentication in the Persona Dashboard here. If it is failed, investigate the associated Inquiry to determine why. The failure may be a configuration error or user error.

The Persona Inquiry flow is passing, but OAMP fails

If the Persona flow opens and passes, but an error is encountered when redirecting to Okta, it is likely that the OIDC ID token does not match what Okta expects. Ensure that you are not writing new values from the Inquiry to the Account’s Verified Claims fields; any mismatch between the Verified Claim values Okta sends and the Verified Claim values on the Persona Account will result in an ID token error.

In the Okta Admin dashboard, navigate to Reports > System Log and filter for outcome.result eq "FAILURE". These logs may include error messages or other context to help identify the issue.

Frequently asked questions

What is changing with the Persona IDV integration in Okta?

Okta has introduced a native Persona IDV integration in the Okta Integration Network (OIN) built on OpenID Connect (OIDC) and Pushed Authorization Requests (PAR). This replaces the legacy, API-key-based Persona IDV chiclet with a modern, standards-based integration that supports Verified Claims.

Why do we need to migrate from the legacy Persona IDV tile?

Okta is standardizing all Identity Verification Provider integrations on OIDC with PAR to ensure greater security, protocol compliance, and tighter integration with Okta Identity Engine (OIE). The legacy integration relied on static API keys and direct polling of inquiry endpoints. Because Okta is deprecating the legacy chiclet, customers must migrate to the new OIDC-based integration before the legacy solution reaches End-of-Life (EOL).

What is the migration timeline and End-of-Life (EOL) date?

The new Persona IDV OIN integration becomes available on September 15, 2026. The legacy API-key-based Persona IDV integration will reach End-of-Life (EOL) on September 15, 2027. Organizations have a one-year migration window to test and transition their Account Management Policies to the new OIN integration.

If we already configured Persona via “Custom ID verification”, do we need to migrate?

No immediate action is needed. If your organization already configured Persona using Okta’s Custom ID verification option (entering Persona’s OIDC and PAR endpoints manually, which is common in FedRAMP and custom tenant environments), your deployment already runs on the same modern OIDC and PAR architecture. You do not need to reconfigure your integration unless you wish to switch to the pre-built OIN catalog tile.

Will migrating to the new integration disrupt employees or require re-verification?

No. Migrating between the integration tiles does not disrupt end users or require employees to re-verify their identities. Persona maintains verification history and account associations using the employee’s unique Okta ID passed via login_hint (or reference-id). Existing verified statuses are preserved, and employees will only be prompted to complete an inquiry when triggered by an active Account Management Policy rule.

What attributes are verified and passed between Okta and Persona?

When Okta triggers an identity verification flow, it sends the employee’s base truth profile attributes (such as given_name and family_name, and optionally birthdate or custom attributes) to Persona over PAR as Verified Claims. Persona compares the information extracted from the government ID against these Okta claims. When the verification completes, Persona issues a signed OIDC ID token returning the verified claims (and optional indicators such as id_verified) back to Okta to validate the employee’s identity.

What Okta architecture and feature licenses are required?

Identity verification is supported only on Okta Identity Engine (OIE) tenants; Okta Classic is not supported. In addition, the Okta tenant must have the Adaptive Multi-Factor Authentication (AMFA) or Multi-Factor Authentication (MFA) feature enabled to configure Account Management Policies (OAMP) and route users to an external Identity Verification Provider.

Why do OAuth credentials stop working after 90 days, and what is the recommended fix?

Okta OAuth 2.0 app credentials enforce a non-extendable maximum lifetime of 90 days. When this window expires, API calls fail with 401 Unauthorized errors, which blocks automated workflow actions like profile lookups or factor resets.

For production integrations, use Okta API Services with Private Key JWT (JWKS) rather than standard OAuth credentials. Persona provides a public JWKS URL that you configure in your Okta API Services application, establishing durable, non-expiring machine-to-machine authentication that is not tied to an individual administrator’s account or subject to a 90-day expiration window.

How are attribute matching and Verified Claims handled?

When Okta initiates an identity verification flow via PAR, it supplies base truth claims (such as given_name and family_name). Okta requires an exact match between what it sent and the verified claims returned in the ID token.

• Do not overwrite base truth claims on the Account: The Inquiry Template must not overwrite or modify Account fields that store Okta-provided base truth claims. If the Inquiry writes a different value (such as replacing the Okta first name with an OCR extraction that includes or omits a middle name), the returned token will not match what Okta sent, and Okta will reject the authentication.
• Handling name mismatches: Compare the extracted name from the government ID against the Okta-provided claim within the Inquiry checks, but keep the Okta-provided claim as the stored value on the Account.
• Capturing extra attributes: Only configure claims in the Authentication Template that you intend to verify. If you need additional employee attributes (such as email, department, or manager) for workflow routing, use the Persona Okta Marketplace integration in a Workflow to retrieve the user’s Okta profile by their Okta ID (login_hint) rather than passing unverified claims through PAR.

What happens if an employee fails verification or the session times out?

• Verification failure: If an employee fails verification (such as presenting an invalid ID, failing selfie liveness checks, or having mismatched identity data), Persona returns a failed authentication response to Okta. Okta blocks the protected action and prevents the employee from proceeding.
• Session timeout: Okta enforces a 10-minute timeout window on identity verification sessions. If an employee takes longer than 10 minutes to complete the Inquiry, Okta times out the request, and the employee must restart the flow from Okta.
• Fallback paths and manual review: You can configure Persona Workflows and Cases to route failed or inconclusive inquiries to a manual review queue for IT helpdesk or Security Operations review. This allows administrators to inspect verification signals and conduct out-of-band verification before approving the employee’s request.

Plans Explained

Okta Integration by plan

Learn more about pricing and plans.