JacobD.07175 (Customer) asked a question.
Unable to achieve passwordless with email MFA as option for a single application
Preferred Option 1
I was asked to have an application require email authentication and the choice of phone, okta verify, google auth or a fido key. I believe this is not a possible combination as it would be 2 possession and no knowledge (tell me if I am wrong) so I tried for the next best thing.
Option 2
The next best thing for us would be no password and single possession factor with choice of email, phone, okta verify, google auth or a fido key.
I created an enrollment policy which applied only to the group that is allowed to log into the target App, and applied only when the App was being access. For enrollment policies, one factor always has to be set to required. So this eliminated giving a choice of MFA. Also, password still seemed to be collected regardless and asked before the required MFA option was set.
Option 3
Now I am trying for a second backup option -- password required and choice of second factor to include email, phone, okta verify, google auth or a fido key. When I see all second factors as optional including email, email gets auto enrolled and the user is not given a choice for the second factor--but only for an optional third factor. 3 factors would be too much for this audience. I attempted activating the early access feature "Enable optional email enrollment for Okta Identity Engine" but that had no affect. When I set the email authenticator to recovery only, the flow is OK with a choice of factors. But email is not included as is needed for a certain portion of our users. Also, password is collected and then asked again when MFA is set. It feels like too drawn out of a flow for this audience
How Tested
With each of these, I tested as we would plan to run things in prod. I created a user via API but did not activate. I then did another API call for an activationToken, which I put in a link similar to the following:
That seemed to take the user directly to the app and from looking at logs, does not seem to trigger other apps or their policies such as Okta dashboard or the default log in page for the custom domain.
Goal
I would ideally like to achieve Option 1. Option 2 is preference and option 3 is last. Other alternatives are welcome. We are trying to create secure self-service access for a population that may not be largely tech savvy and where minimal phone support resources are available.
Updating this response for ease of access and reference:
Overview
Administrators may attempt to configure an Okta authentication policy that requires email authentication alongside a choice of other factors, such as phone, Okta Verify, Google Authenticator, or a FIDO key. During testing, administrators may generate an activation token via API and use a link similar to Custom Domain Token Verification to direct users to the application. Okta does not currently support this specific configuration due to security constraints regarding email authenticators and unmanaged devices.
Applies To
Solution
Is it possible to require email authentication and a choice of other factors?
Okta does not currently support configuring an authentication policy that requires email authentication alongside a choice of other factors. The security level of email authenticators and the lack of device management for the user base prevent this configuration.
Okta provides alternative authentication methods for passwordless access.
Implement passwordless authentication by configuring Okta FastPass with device management or by developing a custom Email Magic Links integration.