Skip to content
Go to Dashboard

How to trigger Persona identity verification within Okta (legacy)

⚠️ This article describes a legacy integration. It is superseded by the

Persona IDV OIN integration, which uses OIDC instead of a Persona API key. New customers should follow that article instead. If you’re already using the integration described here, see Migrating to the new solution below.

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 managed 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 easily integrated, offers an added component of security to access controls, and helps keep employees from being blocked.

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.

  1. Follow the steps here and add Persona as an Identity Provider. If you have multiple Persona templates you want to use, make sure to name the Identity Provider appropriately so you can distinguish between them (we recommend the same name as the Persona Inquiry Template).
  2. Fill in the Persona values (see below) and Save.
  3. By default, Okta passes a first name and a last name to Persona. Configure Okta to also send the email address to Persona using the Map profile attributes from Okta to an identity verification vendor. This is necessary to facilitate identity verification experiences in Persona.

Fetching Persona values

You’ll need your Persona API Key and your Inquiry Template ID.

  • Your Persona API key can be found at API > API Keys. Ensure you’re copying your Production API key.
  • Your Inquiry Template ID can be found in the ID column in the Inquiry > Templates page of the Persona Dashboard. It starts with itmpl_.

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 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 inquiry for the employee with:
    1. The API key and template provided in the IDP configuration
    2. The employees Okta ID as the Persona account’s reference-id (which will serve as the account identifier for Persona)
    3. The employees’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 employees 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 employees has completed the inquiry, they will be redirected back to an Okta webpage
  4. Okta will make a call to GET the inquiry result. If the status is completed (all verifications have passed), the employee will be allowed to continue. If the status is failed (at least one verification has failed), the user be prevented from continuing.

Note that employees will have a limited period of time to complete identity verification. If they take more than five 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

Migrating to the new Persona IDV integration

  1. Follow the setup instructions in How to trigger Persona identity verification within Okta using the Persona IDV integration to build a new Persona Authentication Template and add a new Persona Identity Provider in Okta.
  2. Once the new Identity Provider is working end-to-end (test it against a group before rolling out broadly), edit your Okta Account Management Policy rule and change the Identity Verification Service to point at the new Identity Provider, replacing the legacy one described in this article.
  3. After you’ve confirmed employees are being routed through the new solution, you can remove the legacy Identity Provider and revoke the Persona API key that was used for it.

FAQ

What changes do I need to make to my existing template in order to work with the new solution?

The legacy integration described in this article authenticates with a Persona API key and Inquiry Template ID configured directly on the Okta Identity Provider; Okta creates the Inquiry via the API, then polls GET the inquiry result for a completed/failed status. The new Persona IDV integration instead authenticates via an OIDC Authentication Template and Verified Claims, so a few things change on your existing Inquiry Template:

  • Connect an Authentication Template. The legacy flow has no Authentication Template — you’ll need to create one and connect it to your existing Inquiry Template, then enable Okta’s redirect URI, PAR, and PKCE on it.
  • Stop writing verified fields back to the Account from the Inquiry. In the legacy flow, an action like Update Account from Inquiry is harmless, since Okta only ever checks the Inquiry’s status. In the new flow, Okta validates the Verified Claims in the returned ID token against the Account’s current values, so if your Inquiry Template writes to those same fields on the Account (e.g. given_name, family_name), the check will fail. Remove or rescope any such actions so they don’t touch your mapped Verified Claims fields.
  • Map your Verified Claims, including any custom “verified” boolean fields (e.g. id_verified) your configuration needs, set via the Update Object action only at the point a value is actually verified.
  • Add a field to capture the Okta user identifier, and map the login_hint query parameter to it. This replaces the legacy flow’s use of the API-provided reference-id for account lookup, and is required if you’re using deferred account creation.
  • Fetch the employee’s email via a Marketplace integration, if you need it on the Account. The legacy flow only ever populates first and last name as Inquiry fields; add a Workflow step using Persona’s Okta Marketplace integration to look up the email address directly from Okta instead of adding a synthetic “always verified” claim.

Do I need to keep my Persona API key?

No. The new solution authenticates using your Authentication Template’s Client ID and Client Secret rather than a Persona API key. Once you’ve confirmed the new Identity Provider is working, you can revoke the API key that was scoped to the legacy integration.

Will my existing verification checks and branding carry over?

Not automatically — the new solution uses its own Inquiry Template (or a modified version of your existing one, per the changes above), so you’ll need to re-apply any custom verification checks, theming, and copy you’d configured previously.

Plans Explained

Okta Integration by plan

Startup ProgramEssential PlanGrowth PlanEnterprise Plan
Okta IntegrationNot AvailableNot AvailableLimitedAvailable

Learn more about pricing and plans.

Was this article helpful?
Thanks for the feedback. It helps us improve these docs.