About Microsoft Entra external authentication methods
Microsoft Entra supports external authentication methods. With these methods, a third-party provider such as Persona can be a multifactor authentication (MFA) factor in Entra ID.
When Persona is an external authentication method, your Entra administrator can use Conditional Access to require a live identity verification, for example a government ID and selfie check. The employee must complete this verification before they can access a sensitive application, do a sensitive action, or add or change their sign-in methods. This helps to protect your workforce against social engineering, deepfakes, and account takeover at the most important moments.
How it works
- A user tries to sign in to an application or to do an action. An Entra Conditional Access policy that requires MFA protects that application or action.
- Entra redirects the user to Persona as their external authentication method.
- The user completes a verification inquiry (for example, a government ID and selfie check).
- After a successful verification, Persona returns an OIDC success response to Entra.
- Entra grants the user access.
Microsoft Entra Configuration Guide
Do the steps below to configure Persona as an external authentication method in Microsoft Entra.
1. Register an app in Microsoft Entra
- Go to entra.microsoft.com and then go to App registrations > New registration.
- Name the registration (for example, “Persona External MFA”).
- Set Supported account types to single tenant.
- Add a Web redirect URI:
https://authenticate.withpersona.com/authenticate/oidc/authorize - Under API permissions, add the
openidandprofilescopes. - Write down the Application (client) ID and the Directory (tenant) ID from the Overview page of the app registration. You need both in the next step.
2. Configure the Persona authentication template
Prepare your inquiry template
Create or select an inquiry template with at least a selfie verification step. The selfie satisfies the Entra face AMR (Authentication Methods Reference) claim. Do not remove it. Without it, Entra does not accept Persona as a multifactor authentication factor.
Add a new account identifier
The Entra id_token_hint gives two identifiers. Persona must keep them separate:
| Claim | Description | Maps to |
|---|---|---|
oid | The identifier of the user in the Entra tenant. Entra APIs and the Marketplace integration use it. | reference_id |
sub | Specific to the app registration that you created in Step 1. Valid only for this MFA integration. | A new custom identifier |
In the Persona Dashboard, go to Account Types. Add a new identifier field (for example, “Entra MFA subject”) to your account type. Enable it as an Identifier.
Configure your authentication template
In your authentication template:
- Allowed redirect URIs:
https://login.microsoftonline.com/common/federation/externalauthprovider. This value is the same for all Entra tenants. - Allowed response types:
id_token - Token endpoint authentication method: Client Secret POST
- Skip account creation: Keep this off. Persona creates the account from the Entra
id_token_hint. Thus, Persona records the new identifier before it responds to Entra. - Account lookup
- Hint type: ID token hint
- ID token hint issuer:
https://login.microsoftonline.com/{your-entra-tenant-id}/v2.0. Use the Directory (tenant) ID from Step 1. - ID token hint audience: the Application (client) ID of the app registration from Step 1
- ID token hint to account identifier mapping: Map
sub→ your new “Entra MFA subject” identifier. Mapoid→reference_id. - ID token subject: your new “Entra MFA subject” identifier
Save the template. Then copy the Client ID and Client Secret from its Clients section. You need the Client ID in Step 4. Keep the client secret as safe as an API key.
3. Configure Persona Marketplace Integration for Employee Data
Context
Persona must make sure that the employee in the verification is the person who owns the Entra account. To do this, Persona compares the values from the government ID of the employee with the values in their Entra user profile.
Persona keeps the oid from Entra as the Reference ID of the Persona account. The workflow of your inquiry template has a Retrieve Entra user step. This step uses the Microsoft Entra Marketplace integration to find the employee in Microsoft Graph with that ID. The step then fills the name_first, name_last, and email_address fields of the inquiry for the comparison.
Make sure that the names in Entra are the legal names of employees, not preferred names or nicknames. By default, the Retrieve Entra user step reads the standard givenName and surname fields. Your legal names can be in a different location, for example a directory extension or a custom security attribute. If so, add that attribute to the $select parameter of the step. Then map it to name_first and name_last in the Update Inquiry step of the workflow. If Entra does not keep legal names, get them from a different system of record instead, for example your HRIS.
Set up profile attribute mapping
- In the Persona Dashboard, go to Integrations > Marketplace > Microsoft Entra ID. Add a credential as Connect Microsoft Entra ID to your Persona account tells. Make sure that the connection works before you continue.
- Open your inquiry template. Click the edit icon to open its workflow. In the Retrieve Entra user step, select the credential that you added. If Persona configured your inquiry template for you, this step is already there. But it points to a placeholder credential, and it fails until you point it to your credential.
- Check the date of birth mapping. Entra ID has no standard date of birth attribute. Thus, by default,
birthdateis empty. If you keep date of birth in an extension attribute, add it to the$selectparameter of the step. Then map it tobirthdatein Update Inquiry. If you do not, remove the date of birth requirement from the inquiry comparison check of the government ID. The check then shows what it actually compares. - Publish the workflow and the inquiry template.
If Persona configured your inquiry template for you, it includes two workflows. One sends an email to the employee when an inquiry completes. The other sends an email to your administrators and the employee when an inquiry fails. These workflows are inactive at the start and have placeholder email addresses. Replace the placeholders with your own security and support contacts. Then publish and activate each workflow.
4. Add Persona as an external authentication method
- In Entra, go to Authentication methods > External authentication method > Add external authentication method.
- Client ID: Enter the Client ID from your Persona authentication template (see Step 2).
- App ID: Enter the Application (client) ID from the app registration that you created in Step 1. This app registration is a service account for the integration. It is not the Persona Client ID.
- Discovery endpoint:
https://authenticate.withpersona.com/authenticate/oidc/.well-known/openid-configuration - Enable the method. First, apply it to a pilot group, not to all users.
5. Create a Conditional Access policy
Under Grant, select Require multifactor authentication. Do not select Require authentication strength. Microsoft documents that external authentication methods are not compatible with authentication strength. Thus, Persona cannot satisfy a policy that requires authentication strength.
All MFA methods that the user can use satisfy Require multifactor authentication. Thus, to make sure that the policy requires Persona, Persona must be the only MFA method that is enabled for the target group. Under Authentication methods > Policies, exclude that group from your other MFA methods, for example Microsoft Authenticator, SMS, and voice call. If other methods stay enabled for those users, they can satisfy the policy without Persona.
- Go to Entra ID > Conditional Access > Policies and select New policy.
- Under Assignments > Users, include your pilot group. Exclude your emergency access (break-glass) accounts. This prevents a configuration error from locking out all administrators. Also exclude guest and external users, because they cannot use the external authentication method of your organization.
- Under Target resources, select what the policy protects. The options are below.
- Under Access controls > Grant, select Grant access. Check Require multifactor authentication.
- Set Enable policy to Report-only and select Create. Review the results of the policy in Entra ID > Monitoring & health > Sign-in logs. Make sure that it applies to the users that you expect. After your test users register Persona (see Step 6), change it to On.
Require Persona to access applications
To use Persona as general MFA, select Resources under Target resources. Then include All resources, or select the specific sensitive applications that you want to protect.
Require Persona as step-up authentication
To require Persona only for specific sensitive actions, create an authentication context under Entra ID > Conditional Access > Authentication contexts. Tag it in the applications that support it. In your policy, under Target resources, select Authentication context and select your context. Under Session, set Sign-in frequency to Every time. The user then verifies with Persona at each step-up and does not use an earlier MFA again.
Require Persona to register security info
Security info is the methods that users use for MFA and self-service password reset (SSPR). To require Persona verification before users add or change their security info, select User actions under Target resources. Then check Register security information. This is the Microsoft Entra equivalent of an account management policy.
- We recommend that you do not exclude trusted locations from this policy. Then Persona verifies each registration or change at all locations.
- Optional: Under Session, set Sign-in frequency to Every time. Then each time requires a new Persona verification, and an earlier MFA is not used again.
- Since July 6, 2026, this user action also applies when users register Windows Hello for Business or macOS Platform SSO credentials. Make sure that users who configure new devices can complete Persona verification.
- This policy does not control the SSPR password reset. Your SSPR authentication method settings control password reset.
6. Test the integration
-
Sign in to the account of the test user at mysignins.microsoft.com/security-info. Select Add sign-in method > External MFA.
Note: Do not use the back button of your browser during setup. If you must try again, close the tab and start again from the link above. If you do not, Entra shows an error.
-
Complete the Persona verification to register the factor.
-
In the Persona Dashboard, make sure that the authentication succeeded. Make sure that its account has the two identifiers: the Reference ID and your “Entra MFA subject” identifier.
-
After the sign-in method is registered, add the test user to the group of your Conditional Access policy. Then sign in to an application or do an action that the policy protects. Entra should tell you to complete Persona verification as your MFA step.
-
Also test the failure path. Fail an inquiry on purpose. Make sure that Entra denies access.
Add yourself (or a test user) to a Conditional Access group that requires this MFA method only after you successfully register the sign-in method above. If you enable enforcement first, the user can be locked out of their account.
Related resources
- Microsoft Entra integration overview
- Using Persona Workflows to manage Microsoft Entra users & profiles
- How to configure Persona Authentications with OpenID Connect
- Microsoft Learn: Manage an external authentication method in Microsoft Entra ID
- Microsoft Learn: Control security information registration with Conditional Access
Plans Explained
Microsoft Entra Integration by plan
| Startup Program | Essential Plan | Growth Plan | Enterprise Plan | |
|---|---|---|---|---|
| Microsoft Entra Integration | Not Available | Not Available | Limited | Available |