About Okta External Identity Providers
Okta supports external identity providers. An external identity provider is a third-party provider that authenticates users in an Okta org. You can add an external identity provider as an IdP authenticator if its usage is Factor only. Okta can then call a third-party provider, for example Persona, as an authentication factor through OpenID Connect (OIDC).
When Persona is an IdP authenticator, your Okta administrator can use authentication policies to require a live identity verification. The employee must complete this verification before they can access sensitive applications, for example applications with production or financial data. This helps to protect your workforce against social engineering, deepfakes, and account takeover at the most important moments.
This is different from the Persona Okta integration as an IDV identity provider. Only the Okta account management policy (OAMP) triggers that integration.
Configure the Authentications product feature to get the client ID and client secret that you use below.
Okta Configuration Guide
Do the steps below to configure Persona OIDC as an Identity Provider in Okta.
1. Configure the Persona authentication template
In the Persona Dashboard, open your authentication template and configure the following settings:
- Allowed redirect URIs:
https://<subdomain>.okta.com/oauth2/v1/authorize/callback. Replace<subdomain>with the subdomain of your Okta org (for example,companyincompany.okta.com). If your Okta org also uses a custom domain, add the same path on that domain, for examplehttps://login.example.com/oauth2/v1/authorize/callback. After you create the identity provider in the next step, Okta shows the exact value as the Redirect URI on the identity provider page. - Skip account creation: Turn this on. Map the
login_hintto the email address account identifier. Okta sends the login email of the employee as thelogin_hint. To learn how Persona finds or creates the account, read Step 5.
Then, on the account type, enable the Identifiers configuration for the email address field. This makes sure that each email address belongs to only one account.
2. Add Persona OIDC as an Identity Provider
In the Okta Admin Dashboard, navigate to:
- Security > Identity Providers > + Add Identity Provider
- Select OpenID Connect. Scroll down and click Next. Enter the details below and save.
General Settings
- Name:
Persona IDP(use a name that is different from “Persona IDV”) - IdP Usage: Factor only
- Scopes: No changes
Client Details
- Client ID: get from Persona Dashboard in Authentications
- Authentication Type: Client secret
- Client Secret: get from Persona Dashboard in Authentications
- Authorize Requests: No changes
- PKCE: No changes
Endpoints
Use the values below or copy them from:
https://authenticate.withpersona.com/authenticate/oidc/.well-known/openid-configuration
To test with your sandbox environment, use this configuration instead: Openid Configuration
Authentication Settings
- No setting changes
JIT Settings
- No setting changes
3. Add the IdP as an Authenticator
Navigate to:
- Security > Authenticators > Add Authenticator > IdP Authenticator
- Select the newly created Persona OIDC.
4. Update Authentication Policies
Navigate to:
- Security > Authentication Policies
- Create a new policy or edit an existing one.
Exclude at least one admin or group from this policy. This keeps administrator access if Persona OIDC is not available.
For tests, the Okta Dashboard policy can be useful.
Steps:
- Edit the Catch-all Rule or create a new rule.
- Under Authentication Methods, select: Allow specific authentication methods > Persona IdP
5. Configure Persona Marketplace Integration for Employee Data
Context
Persona requires API access to your Okta tenant to get employee profiles.
The Persona account of each employee has two identifiers:
- The Reference ID is the Okta user ID of the employee.
- The email address is the Okta login email of the employee.
The Okta IDV integration uses the same accounts. Thus, an employee who uses the two integrations has one Persona account.
Okta sends the login email of the employee to Persona as the login_hint. Persona defers account creation for this flow:
- The authentication starts without an account.
- Your Inquiry uses that email to find the employee in Okta.
- The Inquiry finds or creates the account with the Okta user ID, and records the two identifiers on the account.
- A Workflow then attaches the account to the authentication.
Set up profile attribute mapping
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.
In the authentication flow, Okta sends only the login email of the employee. Use the Persona Okta Marketplace integration to find the profile of the employee with this email. Persona can then compare the attributes. The same search also returns the Okta user ID of the employee. Persona uses this ID to find or create the account, and records it as the Reference ID of the account.
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.
- Use the Okta Marketplace integration guide to create an Okta API credential that has permission to get users. In the Persona Dashboard, add the credential under Integrations > Marketplace > Okta. Click Test to check the connection.
- In a Persona Workflow, add an Okta Retrieve a user integration action. Use the username from the OIDC authentication to find the Okta profile of the employee. If you use custom attributes, for example
legalFirstNameorlegalLastName, enterprofile:(legalFirstName,legalLastName)in Fields to include. To get all profile attributes, leave the field empty. - Map the legal first and last names from Okta to the Persona fields that your verification flow compares with the government ID. Look at the Okta profile of a test employee and at the Workflow output. Make sure that the mapped values are legal names, not nicknames.
Related resources
- Okta integration overview
- How to configure Persona Authentications with OpenID Connect
- Okta: External Identity Providers
Plans Explained
Okta Integration by plan
| Startup Program | Essential Plan | Growth Plan | Enterprise Plan | |
|---|---|---|---|---|
| Okta Integration | Not Available | Not Available | Limited | Available |