Registering a new user with IDX and Java

Questions API
,
1

Another approach to a user registration with IDX this time in Java.

Here is the list of things configured:

  1. Email verification is required for new users
  2. Email, Phone, etc all are Optional in the enrollment policy, only Password is required

What I see is:

  1. After I call idxWrapper.register(...) I get back 2 available authenticators to enroll into: password and email
  2. I choose password and successfully enroll and verify it
  3. After that I’m getting back a response where status is “awaiting_authenticator_enrollment” and the list of authenticators is null

My question is: how to proceed at this point? I receive an email with the verification button, but what am I expected to do on the backend with the given combination of a status and authenticators?!

Thanks in advance,
Philipp

2

What version of idx-java you’re using? And are you using a specific policy? Also, did you add custom code inside the idxwrapper.register?

3

Thank you, @Sherry, here is the code I’m using

fun main() {
    val idxWrapper = IDXAuthenticationWrapper()

    // begin transaction
    var rsp = idxWrapper.begin()

    // get proceed context
    var ctx = rsp.proceedContext

    // enroll user
    rsp = idxWrapper.fetchSignUpFormValues(ctx)

    print("first name: ")
    val fName = readLine()
    print("last name: ")
    val lName = readLine()
    print("email: ")
    val email = readLine()

    // set user profile
    val userProfile = UserProfile()
    userProfile.addAttribute("lastName", lName);
    userProfile.addAttribute("firstName", fName);
    userProfile.addAttribute("email", email);

    ctx = rsp.proceedContext

    // register user with proceed context
    rsp = idxWrapper.register(ctx, userProfile)
    ctx = rsp.proceedContext
    val authenticator = rsp.authenticators.first { authenticator -> authenticator.type == "password" }

    rsp = idxWrapper.selectAuthenticator(ctx, authenticator);
    ctx = rsp.proceedContext

    print("password: ")
    val pwd = readLine()
    var options = VerifyAuthenticatorOptions(pwd)
    rsp = idxWrapper.verifyAuthenticator(ctx, options)
    ctx = rsp.proceedContext

    rsp = idxWrapper.selectAuthenticator(ctx, rsp.authenticators[0])

3.0.4 is the version of the library and not sure about your policy question. Can you please clarify which policy might affect my use case?

4

I ran a similar program and changed,

    val authenticator = rsp.authenticators.first { authenticator -> authenticator.type == "password" }
    rsp = idxWrapper.selectAuthenticator(ctx, authenticator);
    ctx = rsp.proceedContext

to,

    val authenticator = rsp.authenticators.first { authenticator -> authenticator.type == "password" }
    //rsp = idxWrapper.selectAuthenticator(ctx, authenticator);
    rsp = idxWrapper.enrollAuthenticator(ctx, authenticator.getId());
    ctx = rsp.proceedContext

I tested in Java so getId() I assume is just .Id

You might also look at the sample app where instead of passing null for Credentials in the register() call you pass a password.

5

Hey Philipp!

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!

Cheers!

1 Like
6

Hi Erik, thx for looking into this.

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

7

Thank you @expertopinionsa12 ! I can guess/deduce that too :slight_smile: 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 :slight_smile:

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.

Regards!

8

Hey @Philipp!

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.

Thanks for bringing this up!

1 Like
9

Hi @phi1ipp,

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[0]. 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[0] is to enter the passcode from the email, remediation[1] 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[0] 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.

Thank You,