Limit user signup to corporate email domains

Hi:
I want to configure auth0 such that only users with corporate email domains signup, i.e. I don’t want users with a personal email (specifically where their email domain is gmail.com, yahoo.com, hotmail.com, hey.com)…I tried a couple of approaches and neither yields a satisfactory user experience:

a) Approach #1: Block @gmail.com users from logging in or signing up with Google Login --this solution detects in the Login flow if a user’s email domain is not allowed and then redirects back to the Login page with a error message in the URL…it doesn’t show the Error in a nice way to the user

Specifically the URL looks like this: https://<development_url>/?error=access_denied&error_description=You%20are%20not%20allowed%20to%20access%20this%20resource&state=%3D%3D

b) Approach #2: I implemented a Pre User Registration Action as follows:

/**
* Handler that will be called during the execution of a PreUserRegistration flow.
*
* @param {Event} event - Details about the context and user that is attempting to register.
* @param {PreUserRegistrationAPI} api - Interface whose methods can be used to change the behavior of the signup.
*/
exports.onExecutePreUserRegistration = async (event, api) => {
         var invalidDomains = ["@gmail.", "@yahoo.", "@hotmail.", "@hey."]; 

 function isEmailGood(email) {
            for (var i = 0; i < invalidDomains.length; i++) {
                var domain = invalidDomains[i];
                if (email.indexOf(domain) != -1) {
                    return false;
                }
            }
            return true;
        } if (event.user.email && !isEmailGood(event.user.email)) {
    api.access.deny(`Deny`,`Please enter your business email address`);}};

While the validation logic works and user is not able to signup with a personal email address (as defined by the domains), the error experience for the user is quite confusing…

i) If the Authentication Profile is “Identifier First”, then the Error message is shown only after user enters password [vs in the first screen with email] and the error on Form Submit shows a red box around the Password field vs the Email field
ii) If the Authentication Profile is “Identifier plus Password”, then a generic red error message “WE’RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO SIGN UP.” shows up without giving user a helpful error message.

How can I create a nicer user experience which validates the email during user signup, prevents users with personal email to sign up, and gives users a nice helpful message to use their business email instead?

Hi @vraghuraman,

Welcome to the Auth0 Community!

If I use the follow demo Action:

/**
* Handler that will be called during the execution of a PreUserRegistration flow.
*
* @param {Event} event - Details about the context and user that is attempting to register.
* @param {PreUserRegistrationAPI} api - Interface whose methods can be used to change the behavior of the signup.
*/
exports.onExecutePreUserRegistration = async (event, api) => {
  api.access.deny("All Access Denied Error:","This is a custom error message.");
};

I see this custom error message when I log in with Identifier + Password profile:

Can you please confirm you have your login set to New Universal Login?

Hi Dan:

Confirming that I have login set to New Universal Login…and the experience you show in the screenshot is very similar to what I saw earlier in my scenario i) above. Now I confirmed that in scenario ii) also I get the same red box around the “Password” field. My question is in what you see in your screenshot, is there a way to alert the user that their email address is the “bad field” and have the red error box around that, with the “This is a custom error message” below the email text box…currently as you see, the error message focusses on the password text box, which is not the problem field when we are doing email validations.

Best,
Vijay

It appears that this is the only way to render the error at the moment. I agree with your observation; it would certainly make sense to highlight the email field in this instance as it is the field causing the error.

It’s possible to make a Feature Request for that, which will help us understand demand and use case.