Configure XFA on Okta as an Authenticator

Configure XFA on Okta as an authenticator to add device verification to sign-in. Okta authenticates the user, XFA checks the device against your configured policy, and access continues when the device decision allows it. Use it to confirm the required settings and test the authentication flow before rollout.

Note: This guide assumes that you have an account set up with XFA for your organization and you're an admin for that organization on both XFA and Okta. If you do not have an account, you can create one at https://dashboard.xfa.tech/signup.

This guide uses Okta Identity Engine. Start with one test application and a small test group, then extend the configuration after a successful sign-in test.

Create an integration in XFA Dashboard

After logging in to the XFA Dashboard, navigate to the Enforcement page, click on New and select Okta as the integration type. You'll receive the following information:

Issuer URI
Single Sign-On URL
a certificate you can download by clicking on Download Certificate.

Keep this information handy as you'll need it in the next step.

Note: You'll fill in the remaining information after the creation of the Identity Provider in Okta. Leave the tab open for now.

Create a trusted IdP in Okta to use as authenticator

In Okta, navigate to Security > Identity Providers and click on Add Identity Provider.

Select the SAML 2.0 IdP option, click Next and fill in the following information:

Name: XFA
IdP Usage: Factor only (do not enable 'Account matching with Persistent Name ID')
IdP Issuer URI: (Issuer URI from the previous step)
IdP Single Sign-On URL: (Single Sign-On URL from the previous step)
IdP Signature Certificate: (Upload the certificate you downloaded from the previous step)
Request Binding: HTTP-POST
Sign SAML Authentication Requests: (checked)
Request Signature Algorithm: SHA-256
Response Signature Algorithm: SHA-256
Destination: (leave empty)
Okta Assertion Consumer Service URL: Trust-specific
Max Clock Skew: (leave on default setting)

Click Finish to create the IdP.

You'll receive information about your created Identity Provider, copy the following values for the next step:

Assertion Consumer Service URL
Audience URI

Complete the integration in XFA Dashboard

Go back to the XFA Dashboard and fill in the remaining information for the Okta integration:

Assertion Consumer Service URL: (Assertion Consumer Service URL from the previous step)
Audience URI: (Audience URI from the previous step)
Require signed requests: on
Service provider signing certificate: Okta's signing certificate. In Okta, open the XFA identity provider, download its SP metadata and copy the value between <ds:X509Certificate> and </ds:X509Certificate>. XFA accepts the whole PEM certificate or only that value.

Signed requests let XFA trust which user a sign-in request from Okta names.

warning

Check Sign SAML Authentication Requests in Okta before you paste the certificate. Once XFA has the certificate, it rejects unsigned requests, and every Okta sign-in fails until Okta signs them.

To limit sign-in to your own users, turn on Only allow your email domains and add your domains under Allowed email domains. Only users with an email address on those domains, or on your organization's email domains, can then sign in through Okta. With no domains at all, no one can.

Click Next to save the integration and tweak any policies you want to change.

Add the XFA trusted IdP as Authenticator in Okta

To make the factor-only trusted IdP available as an authenticator, navigate to Security > Authenticators and click on Add Authenticator.

Select the IdP Authenticator option and select the IdP created in the previous steps by the name (e.g. XFA).

Next steps

Make XFA required for users or applications

Configure the application policy before making XFA available in the enrollment policy. Use a test application and a small Okta group containing a non-admin test user who has already joined your XFA organization and has access to the test application.

Go to Security > Authentication Policies > App sign-in. Click Create policy, enter a name and description, and create the policy. You can also edit a policy already used only by your test application.
Under Rules, add or edit a rule. Set User's group membership includes to your test group and put this rule above any other rule that would match these users.
In the rule's THEN section, use these settings:

Setting	Value
Access is	Allowed after successful authentication
User must authenticate with	Password / IdP + Another factor
Possession factor constraints are	Leave Phishing resistant, Hardware protected, and Require user interaction unchecked.
Authentication methods	Choose Allow specific authentication methods and select only IdP Authenticator - XFA.
Option to stay signed in	Leave Show after users sign in unchecked.

If your console shows Password + Another factor, use that equivalent option. Keep Phishing resistant disabled: enabling it removes XFA from the available methods.

Confirm that the authenticator summary shows Password and IdP Authenticator - XFA as the additional factor. Set Prompt for password authentication and Prompt for all other factors of authentication to the intervals required by your organization, then click Save.
On the policy's Applications tab, click Add app, add only your test application, and click Done. Keep the Okta Admin Console outside this test.

Make XFA optionally available for users

Go to Security > Authenticators > Enrollment. Edit the policy for your test group, or click Add a Policy to create one.
In Assign to groups, select the same test group. Set the XFA authenticator to Optional, not Disabled, and preserve the requirements for your other authenticators.
Click Create policy or Update policy. Make sure this active enrollment policy takes priority over other policies that match your test group.

note

Optional enrollment does not make XFA optional for the test application. The app sign-in rule above requires XFA, so Okta prompts users to enroll when needed. Required enrollment makes enrollment mandatory for users covered by that enrollment policy; it does not replace the app sign-in rule. See Okta's enrollment policy behavior.

XFA's Built-in passkey can verify identity through a device the user has explicitly trusted with XFA. The app policy still requires two factor types.

Test the connection

Open a private browser window and sign in to the test application with the non-admin test user.
Confirm that Okta prompts for XFA. Complete enrollment if prompted, then complete XFA's identity and device verification.
Confirm that you return to the test application when your configured XFA policy allows access.

If XFA is missing from the rule's methods, check that Phishing resistant is unchecked. If sign-in skips XFA, check the application's assigned policy, rule order, test group membership, and enrollment policy.

After the test succeeds, assign the app sign-in policy to the intended applications and include the intended groups in its rule. Then extend the enrollment policy to the same groups and repeat the sign-in test. Requiring XFA at sign-in does not turn on blocking for failed device checks; XFA's configured policy determines whether to warn or block.