JacobD.07175 (Customer) asked a question.
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.
Hi @JacobD.07175 (Customer) , Thank you for reaching out to the Okta Community!
Unfortunately, I’m not seeing this as being achievable at this time given the level of security that emails may provide and other features may not be viable for a large user base that is not within a managed environment.
There is Okta FastPass, but it’s dependent on the use of the Okta Verify app and device management, which if I understood your request correctly, is not applicable in your use case.
Perhaps you can look into the “Email Magic Link” feature depending on how much development work you can put in:
Presentation Video: https://www.youtube.com/watch?v=TINz578Gu-k
Developer Guide: https://developer.okta.com/docs/guides/email-magic-links-overview/main/
That being said, while looking into this I noticed that you have a support ticket open, so I recommend continuing the discussion with the assigned Technical Support Engineers. They'll be able to access additional tools and resources to help you get to the bottom of it.
If possible, once things are clarified, please post the outcome here for anyone in the Okta Community who may be looking into the same.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--------------------------------
Ask the Experts: Now Thru 1/31 Okta FastPass Engineering and Product Teams Answer Your Questions