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, the Okta Integration Network (OIN) lists Persona as the Persona IDV integration. Thus, Persona is easy to integrate. It adds security to access controls. It also helps prevent blocks on employees.
Quick Start
The Solutions page of the Persona Dashboard has a guided setup here. This setup adds a complete, ready-to-use solution to your Persona organization.
How to set up Persona Authentications for Okta workforce authentication
For this solution, configure Persona Authentications with OpenID Connect. Also configure Verified Claims to work with Okta BYO IDV.
- Use the steps in that article to create an Authentication Template. Connect it to your Inquiry Template.
- Enable these items in the Authentication Template:
- Add Okta’s redirect URI:
https://{yourOktaDomain}/idp/identity-verification/callback - Enable ‘Require Pushed Authorization Requests (PAR)’
- Enable ‘Require PKCE’
- Add Okta’s redirect URI:
- In the Verified Claims section of your Authentication Template, map each claim that Okta must get back to the related field in your Inquiry Template. This mapping controls how Persona writes the base truth verified claim values from Okta to the Persona account. It also controls how Persona sends verified claim values from IDV back to Okta. The exact fields depend on your Okta configuration.
- At a minimum, configure
given_nameandfamily_name. Configure only the fields that you also configured Okta to send. - Your Inquiry Template must NOT change Account fields that Okta set through PAR. The PAR values are the base truth verified claims. Okta expects Persona to verify them and return them with no changes. If the Inquiry changes these field values on the Account, Persona returns verified claim values that do not match what Okta expects. Okta then rejects the authentication.
- You can also configure a custom boolean field, for example
id_verified. This field tells Okta that the Inquiry flow verified the claim value that Persona returns. Your Inquiry Template must use the Update Object action to set this field at the point where it actually verifies values. Data that is not verified must not set this field. An example is a self-reported phone number that Persona collects but does not check with Phone Verification. The exact configuration of these boolean fields depends on the data that your Inquiry template collects and verifies.
- At a minimum, configure
- Record the client ID and client secret. You use them in the next step.
Capturing Okta user profile attributes you don’t intend to verify
Okta expects Persona to verify every value that Okta sends through PAR. Thus, use PAR and Verified Claims only to send attributes that you intend to verify. For example, if you want to keep the email address of the user, do not send it as a Verified Claim. Send it only if you actually intend to verify it (read Email (2FA) Verification).
Instead, use the Persona Okta Marketplace integration in a Workflow to get the user profile of the employee directly from Okta (the Retrieve a user action). When Okta starts the Persona flow, it sends the Okta ID of the employee as the login_hint query parameter. Read this value from the Account and use it in the Retrieve a user action. If you defer account creation, add a mapping from the query parameter to an Inquiry field instead. This mapping writes login_hint into an Inquiry field that you can access later.
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.
Persona must make sure that the employee in the verification is the person who owns the Okta account. To do this, Persona compares the values from the government ID of the employee with the values in their Okta user profile.
Make sure that the names in Okta are the legal names of employees, not preferred names or nicknames. Your Okta user profile has firstName and lastName attributes. If these attributes do not contain legal names, we recommend that you add custom string attributes, for example legalFirstName and legalLastName.
- Add Persona IDV to your Okta tenant as an Identity Provider.
- Enter the Client ID and Client Secret of your Authentication Template.
- Update the User attributes mapping to include the attributes that you want to verify with Persona. Okta sends these attributes to Persona as Verified Claims. This mapping must be EXACTLY the same as the Verified Claims that you configured in the Authentication Template.
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
- When the Authentication Policy rule triggers, the integration creates an OIDC authentication for the employee with:
- The client ID and secret from the BYO IDV configuration.
- The Okta ID of the employee as the
reference-idof the Persona account. This is the account identifier for Persona. - The first and last name of the employee from the Okta Universal Directory, as Inquiry fields.
- 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.
- Okta tells the employee to complete the Persona inquiry. A button in the Okta flow opens a hosted Persona Inquiry page.
- After the employee completes the inquiry, Persona sends the employee back to an Okta webpage.
- If the authentication passes (all verifications passed), the employee can continue. If not (at least one verification failed), the user cannot continue.
Note: Employees have a limited time to complete identity verification. If they take more than ten 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.
Troubleshooting
Persona is not opening when triggering OAMP
If the Persona flow does not open at all, an error probably occurs when Okta tries to create the Persona Authentication.
In the Okta Admin dashboard, go to Reports > System Log and filter for outcome.result eq "DENY". These logs may include error messages or other data that help you find the problem. For example, ReasonForFailure may say PAR response doesn't have an HTTP 201 status code, instead received a status code of 400. This error shows an incorrect configuration. For example, this error can occur if the Verified Claims in the Persona Authentication Template are different from the user attribute mapping in the Okta Identity Provider.
The Persona Inquiry flow is unexpectedly failing
Find the Authentication in the Persona Dashboard here. If its status is failed, examine the related Inquiry to find the cause. The failure may be a configuration error or a user error.
The Persona Inquiry flow is passing, but OAMP fails
The Persona flow can open and pass, and then an error can occur during the redirect to Okta. If so, the OIDC ID token probably does not match what Okta expects. Make sure that the Inquiry does not write new values to the Verified Claims fields of the Account. Okta sends Verified Claim values. If the Verified Claim values on the Persona Account are different, an ID token error occurs.
In the Okta Admin dashboard, go to Reports > System Log and filter for outcome.result eq "FAILURE". These logs may include error messages or other data that help you find the problem.
Frequently asked questions
What is changing with the Persona IDV integration in Okta?
Okta added a native Persona IDV integration to the Okta Integration Network (OIN). It uses OpenID Connect (OIDC) and Pushed Authorization Requests (PAR). It replaces the legacy Persona IDV chiclet, which uses an API key. The new integration is modern, uses standards, and supports Verified Claims.
Why do we need to migrate from the legacy Persona IDV tile?
Okta now uses OIDC with PAR for all Identity Verification Provider integrations. This gives more security, protocol compliance, and closer integration with Okta Identity Engine (OIE). The legacy integration used static API keys and polled inquiry endpoints directly. Okta is deprecating the legacy chiclet. Thus, customers must migrate to the new OIDC 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 Persona IDV integration, which uses an API key, reaches End-of-Life (EOL) on September 15, 2027. Organizations have one year to test their Account Management Policies with the new OIN integration and move them to it.
If we already configured Persona via “Custom ID verification”, do we need to migrate?
No immediate action is necessary. Some organizations configured Persona with the Okta Custom ID verification option. With this option, you enter the Persona OIDC and PAR endpoints manually. This is frequent in FedRAMP and custom tenant environments. If your organization used this option, your deployment already uses the same modern OIDC and PAR architecture. You do not need to configure your integration again, unless you want to change to the pre-built OIN catalog tile.
Will migrating to the new integration disrupt employees or require re-verification?
No. A migration between the integration tiles does not disrupt end users. Employees do not have to verify their identities again. Persona keeps verification history and account associations with the unique Okta ID of the employee. Okta sends this ID through login_hint (or reference-id). Current verified statuses stay the same. Employees must complete an inquiry only when an active Account Management Policy rule triggers one.
What attributes are verified and passed between Okta and Persona?
When Okta triggers an identity verification flow, it sends the base truth profile attributes of the employee to Persona through PAR as Verified Claims. Examples are given_name and family_name, and optionally birthdate or custom attributes. Persona compares the information from the government ID with these Okta claims. When the verification completes, Persona issues a signed OIDC ID token to Okta. The token returns the verified claims, and optional indicators such as id_verified. Okta uses the token to validate the identity of the employee.
What Okta architecture and feature licenses are required?
Identity verification is supported only on Okta Identity Engine (OIE) tenants. Okta Classic is not supported. Also, the Okta tenant must have the Adaptive Multi-Factor Authentication (AMFA) or Multi-Factor Authentication (MFA) feature enabled. This feature is necessary to configure Account Management Policies (OAMP) and to send 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 have a maximum lifetime of 90 days, and you cannot extend it. When this time expires, API calls fail with 401 Unauthorized errors. These errors block automated workflow actions, for example profile searches or factor resets.
For production integrations, use Okta API Services with Private Key JWT (JWKS), not standard OAuth credentials. Persona gives a public JWKS URL. Configure this URL in your Okta API Services application. This gives durable machine-to-machine authentication that does not expire. It is not connected to the account of one administrator, and it does not have a 90-day expiration limit.
How are attribute matching and Verified Claims handled?
When Okta starts an identity verification flow through PAR, it sends base truth claims, for example given_name and family_name. The verified claims in the returned ID token must be exactly the same as the claims that Okta sent.
- Do not overwrite base truth claims on the Account: The Inquiry Template must not overwrite or change Account fields that keep base truth claims from Okta. The Inquiry can write a different value. For example, it can replace the Okta first name with an OCR value that adds or removes a middle name. If it does, the returned token does not match what Okta sent. Okta then rejects the authentication.
- Handling name mismatches: In the Inquiry checks, compare the name from the government ID with the claim from Okta. Keep the claim from Okta as the value on the Account.
- Capturing extra attributes: In the Authentication Template, configure only the claims that you intend to verify. If you need more employee attributes for workflow routing (for example email, department, or manager), use the Persona Okta Marketplace integration in a Workflow. Use it to get the Okta profile of the user with their Okta ID (
login_hint). Do not send claims that are not verified through PAR.
What happens if an employee fails verification or the session times out?
- Verification failure: An employee can fail verification. For example, they show an invalid ID, fail selfie liveness checks, or have identity data that does not match. If so, Persona returns a failed authentication response to Okta. Okta blocks the protected action and the employee cannot continue.
- Session timeout: Okta has a 10-minute timeout on identity verification sessions. If an employee takes more than 10 minutes to complete the Inquiry, the Okta request times out. The employee must start the flow again from Okta.
- Fallback paths and manual review: You can configure Persona Workflows and Cases to send failed or inconclusive inquiries to a manual review queue. The IT helpdesk or Security Operations team can then review them. Administrators can examine the verification signals and verify the employee through a different channel. They do this before they approve the request of the employee.
How do I use my Persona Sandbox environment with the Persona IDV integration?
The Persona IDV integration supports only Production environments. To test in a Persona Sandbox environment, use Okta Custom IDV to configure your integration.
The Persona IDV integration and the Custom IDV integration operate the same way. But with the Custom IDV integration, you must give the metadata URLs for OIDC. The Persona IDV integration gives these URLs for you. With Custom IDV, you can send the metadata URLs that Persona Sandbox environments need. These URLs are here.
Plans Explained
Okta Integration by plan
| Startup Program | Essential Plan | Growth Plan | Enterprise Plan | |
|---|---|---|---|---|
| Okta Integration | Not Available | Not Available | Limited | Available |