Configure Persona for the Okta Account Management Policy (legacy)

What is Okta workforce authentication?

Companies of all sizes use Okta for workforce authentication. Okta is a cloud-based Identity and Access Management (IAM) platform. It manages access to enterprise applications, systems, and resources that must stay secure. It gives secure and simple access to employees, contractors, and partners.

How Persona identity verification supports Okta workforce authentication

Social engineering and deepfake attacks increase. Thus, it is more and more difficult to protect a distributed and remote workforce. Persona adds an important layer of security. It automatically verifies the identities of employees at sensitive moments in the employee lifecycle. Examples are new employee onboarding, account recovery, and changes to sensitive information.

For businesses that already use Okta, Persona is easy to integrate. It adds security to access controls. It also helps prevent blocks on employees.

How to set up Persona as your Identity Provider in Okta

For more information about the Okta Account Management Policy, read the Okta documentation here. Note: Identity verification is available only for Okta Identity Engine tenants, not Okta Classic tenants. It requires MFA/AMFA features.

Fetching Persona values

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

• Your Persona API key is at API > API Keys. Make sure that you copy your Production API key.
• Your Inquiry Template ID is in the ID column of the Inquiry > Templates page of the Persona Dashboard. It starts with itmpl_.

Configuring the policy

Under Security > Authentication Policies, click your Okta Account Management Policy. Click Add Rule and configure the rule as necessary. We recommend that you first apply this rule only to a test group. Under Identity Verification Service, select the applicable Persona Identity Provider.

Updating your Password Policy

Edit your Password Policy rules. Make them use the OAMP to select the authenticators that Okta asks a user for.

Testing the policy

An easy way to test the integration: go to the End User settings in Okta and try to change a security method. This triggers the Account Management policy. The user then goes through the Persona flow.

How the integration between Persona and Okta works

1. When the Authentication Policy rule triggers, the integration creates an inquiry for the employee with:
   1. The API key and template from the IDP configuration.
   2. The Okta ID of the employee as the reference-id of the Persona account. This is the account identifier for Persona.
   3. The first and last name of the employee from the Okta Universal Directory, as Inquiry fields.
   4. A redirect URL to go back to Okta. If you use domain allowlisting, add the domain of your Okta tenant (for example, persona.okta.com). If you do not, Persona rejects the inquiry creation.
2. Okta tells the employee to complete the Persona inquiry. A button in the Okta flow opens a hosted Persona Inquiry page.
3. After the employee completes the inquiry, Persona sends the employee back to an Okta webpage.
4. Okta calls GET the inquiry result. If the status is completed (all verifications passed), the employee can continue. If the status is failed (at least one verification failed), the user cannot continue.

Note: Employees have a limited time to complete identity verification. If they take more than five minutes, they may get an error. They could possibly need to start the verification flow again.

Understanding and making changes to your Inquiry template

Your template has a default configuration that uses our standard recommendations for the Know Your Employee verification experience. You can change it in these ways:

• Update inquiry configurations and verification checks to add or remove friction for your employee. For example, require the capture and scan of the barcode on drivers’ licenses, or accept only IDs from some countries. For a full explanation of Persona verification checks and other configurations, read the Google spreadsheet that we gave to your team.
• Configure the colors of your template to match the brand of your company.
• Add custom text to help your employees through the process.

Migrating to the new Persona IDV integration

Use the migration guide to do these steps:

FAQ

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

The legacy integration in this article uses a Persona API key and an Inquiry Template ID to authenticate. You configure these directly on the Okta Identity Provider. Okta uses the API to create the Inquiry. Okta then polls GET the inquiry result for a completed or failed status. The new Persona IDV integration uses an OIDC Authentication Template and Verified Claims to authenticate. Thus, some items change on your current Inquiry Template:

• Connect an Authentication Template. The legacy flow has no Authentication Template. Create one and connect it to your current Inquiry Template. Then enable the Okta redirect URI, PAR, and PKCE on it.
• Stop writing verified fields back to the Account from the Inquiry. In the legacy flow, an action such as Update Account from Inquiry causes no problem, because Okta checks only the status of the Inquiry. In the new flow, Okta compares the Verified Claims in the returned ID token with the current values of the Account. Your Inquiry Template can write to those same fields on the Account (for example, given_name, family_name). If it does, the check fails. Remove such actions, or change their scope so they do not touch your mapped Verified Claims fields.
• Map your Verified Claims, including custom “verified” boolean fields (for example, id_verified) that your configuration needs. Use the Update Object action to set these fields only when a value is actually verified.
• Add a field to capture the Okta user identifier, and map the login_hint query parameter to it. In the legacy flow, Persona used the reference-id from the API to find the account. This field replaces that. It is necessary if you use deferred account creation.
• Fetch the employee’s email via a Marketplace integration, if you need it on the Account. The legacy flow puts only the first and last name in Inquiry fields. Add a Workflow step that uses the Persona Okta Marketplace integration to get the email address directly from Okta. Do not add a synthetic “always verified” claim.

Do I need to keep my Persona API key?

No. The new solution uses the Client ID and Client Secret of your Authentication Template to authenticate. It does not use a Persona API key. After you make sure that the new Identity Provider works, you can revoke the API key of the legacy integration.

Will my existing verification checks and branding carry over?

The migration wizard copies your current Inquiry Template. It does not start with an empty template. Before you publish the copy, review its checks, theming, text, and connected Workflows. Make the changes that the wizard could not complete.

Plans Explained

Okta Integration by plan

Learn more about pricing and plans.