So, when I call idxWrapper.register(...), I get back two options to sign up: password and email. I choose password and get it all set up and verified. But then, I get a response with a status of “awaiting_authenticator_enrollment” and no list of authenticators. I’m like, “What now?”
Well, it seems that I’ve successfully enrolled and verified my password, but there are still some additional authenticators I need to complete the registration. The missing one is probably the email authenticator.
To move forward, I should receive an email with a verification button. Once I click it, I’ll need to handle the verification on the backend. Once that’s done, I can update my status to indicate that I’ve completed the email verification, maybe something like “awaiting_additional_enrollment.”
After that, I can use IDX to retrieve the updated list of available authenticators, and this time, the email authenticator should be there. From there, I can give the option to enroll in the email authenticator and continue the registration process. At least, this is what I have learnt so far at triotech systems. Hope that helps!
The issue I’m facing happens after password enrollment. Though I found it’s funny that selectAuthenticator requires Authenticator, while enrollAuthenticator requires just String of authN’or Id. But nonetheless it’s not the culprit here.
My point was, that after running my small snippet I’m at awaiting_authenticator_enrollment status, but the list of them returned in rsp is null.
Please check my next response in this thread to see the suggestion/question.
Thank you @expertopinionsa12 ! I can guess/deduce that too my question is how will backend understand this fact?! IDX was developed as an interaction flow where your next step options are embedded into a response you receive from Okta. It seems that in this scenario presented by me, you are left to guess, what you need to do further. But enough of me rambling
So it seems like I’m not the only one running into this weird scenario. I appreciate your time spent on commenting. But I think that here we need some attention from Okta Dev team to polish the flow. And the status at this point can be awaiting_email_verification or something like that, which will clearly say what backend should do at this point, rather than the state currently being used.
Totally get what you’re saying, dude. It’s like Okta’s flow leaves us hanging, right? Like, they don’t give a clear indication of what the backend should do next. It’s all guesswork, man.
I mean, it’s not just me who’s facing this weird scenario. It seems like a lot of peeps are scratching their heads too. Props to you for bringing it up, though. We need Okta’s dev team to step in and polish things up.
Instead of the vague “awaiting_authenticator_enrollment” status, they should just keep it simple and call it “awaiting_email_verification” or something. That way, the backend knows exactly what to do next, without any confusion.
But hey, don’t worry, man. Your feedback matters, and it’s worth letting Okta know about it. Reach out to their dev team or support and share your thoughts. They might have some insights or tweaks to make the user registration process smoother.
I ran a few more tests and output the raw responses from Okta,
My Authenticator Enrollment Policy has Email/Password Required, Verify/SMS are valid options in this applications Authentication Policy though…
The first gist file is the response from selectAuthenticator() where password is selected. The authenticators array still shows password/email, and authenticatorEnrollments already shows email since it is mandatory. The remediation arrays has two options, verify password, select email. I believe our SDKs/samples tend to follow the first remediation option.
The second gist file the response from verifyAuthenticator() for password from the above remediation. In this response the authenticators array does show email, even though when this is mapped to Java Response it shows as null. At this point authenticatorEnrollments now shows password/email, currentAuthenticator shows as email and the email OTP has already been sent. remediation is to enter the passcode from the email, remediation is select-authenticator-enroll for email even though it does not show in the Java Response authenticators. So could be an issue here, but going off of remediation the next step does appear to be verify passcode and it is also already set as currentAuthenticator.
The third gist file is the response from verifyAuthenticator() for passcode from the email. The remediation array shows optional verify/SMS enrollment (coming from a rule in the apps authentication policy) and a skip option. authenticators now shows verify/SMS, email is now removed, and authenticatorEnrollments shows password/email still.
At this point if I do skipAuthenticatorEnrollment() I get back tokens.
So in the call you noted where authenticators is null, the Raw Json response does show email. However the selected authenticator is already set to email and the first remediation array value is to verify the passcode.
Okta does not document this API so I don’t know for sure. You can enter a bug for this, but even if the authenticators array did show email, the next step of entering the passcode from the email already sent would then return result 3 above which no longer would have email as an option in authenticators. It will either have optional authenticators from the enrollment policy, or authenticators that are used in this application Authentication Policy rules, again optional, or no Authenticators at all if there are no optional ones.