Auth0 disallows emails with valid format

Hello,

We’re doing a dry run for user data migration as we prepare to move to Auth0. However we found that in some cases, the email addresses from our registered users are not considered valid by Auth0 and rejected.

Specifically, we have found 2 patterns so far.
One pattern is if there are two or more consecutive periods in the email address. For example:
foo…bar@example.com

The other pattern is if there is a period right before the @ sign. For example:
foo.@example.com

I saw this issue here: Email validation for Auth0

I took the advice and created an input with the default HTML5 type email validator and tried the email addresses. The first case (foo…bar@example.com) is NOT considered valid. However the second case (foo.@example.com) IS considered valid.

It’s kind of a big problem for us, because I don’t think we can ask customers to create a new email account just to have an address that Auth0 considers valid. Of course it’s partly our bad, for allowing people to register with a non-standards compliant email address. But it seems like Auth0 validator is also overly strict blocking some valid email addresses.

Any idea how to overcome this? We’ve already spent over a year preparing for the move to Auth0 to find out just now we’re blocked by this…

Hi @adam.butterfield,

Unfortunately I do not believe we have a good workaround for this scenario. Auth0 validates users’ email addresses according to RFC 2822, and we are unable to change the email validation used since it’s hardcoded and not configurable.

If you are using a custom database with import mode off, then you could always re-format the email address and store the original in the user’s app_metadata. This will add some complexity though that may not be worth while depending on the number of users with invalid emails. In addition, if import mode is on, this would not be suitable since the user would not be able to authenticate with the same credentials once imported as the email address would differ.

Our recommendation would be to look through your current user database to identify which are impacted as it would hopefully be a very small number. From there you can see if it’s possible to change or have them authenticate with a username instead.

1 Like

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