Implementing Custom Validation and Fields for Self-Service Registration in a web app using Okta Classic Engine

Okta Integration Inquiry for AngularJS & Java Play Framework Application

We are integrating Okta Classic Engine for authentication and self-service registration into our application, which uses AngularJS for the frontend and Java with the Play Framework for the backend. We have several specific requirements and questions:

  • Pre-Registration Validation:

    • Our app requires users to enter their email, phone number, and a unique identifier during the registration process. We need to validate these details against our own database before registering the user in Okta. Should we opt for the Okta Sign-In Widget or the AuthJS SDK for implementing this validation step?
  • Deployment Approach (in case of a sign-in widget):

    • Given our pre-registration validation requirement, would an embedded integration or a hosted solution be more appropriate for our application? Does the choice affect extending the solution to support SSO in the future?
  • Third-Party Cookies:

    • From what we understand, an authorization work flow with PKCE seems to be the recommended approach in this case. Given that the third party cookies are going to be deprecated, are there any additional considerations to be taken into account?
  • Two-Factor Authentication:

    • Is it feasible to use the mobile number provided during registration for SMS-based two-factor authentication in Okta?

We seek your advice on the best practices for these scenarios, along with any relevant documentation or examples that could assist in our implementation.

Thank you for your support.

Have you looked into using the Registration inline hook to validate the user input? You can use the hook to deny the user registration if the values don’t match those found in your database

Far as I can tell, this hook will work with the Okta Hosted widget (recommended) or an embedded widget. Redirecting through the Okta domain is the best way to ensure SSO functions completely between your applications and you are less likely to end up in a position where you are blocked from completing an action based on the blocking of 3rd party cookies.

Speaking of 3rd party cookies, we have a couple of posts that cover this in more detail:

For your final question, are you collecting the user’s phone numbers in the base phoneNumber attribute, or in a custom attribute? I’m not as confident in the MFA space as I’d like to be, but you may find that you would need to enroll your user’s separately. In which case, the simplest way to do so would be via an Enrollment policy for these self-service registered users

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.