Auth0 defines a list of allowed characters for a user profile's username value. This can be an issue in custom database migration scenarios, where the legacy custom database and users have usernames that are not compatible with Auth0's username validation. 

This article outlines several options to mitigate this issue so users from a legacy database can migrate their profiles to Auth0.

• Imports
• Allowed Characters
• Legacy Database

Currently, Auth0 does not have the means to relax username validation at the tenant or connection level to allow user migration into Auth0. However, the following are some potential workarounds that may be suitable depending on the use case and intended user journey.

NOTE: The three options listed are suggestions for how to approach this issue and should be rigorously tested to confirm which, if any, will apply to a given user migration scenario.

Option 1

Auth0 does not enforce the allowed characters previously mentioned in a custom database when the migration is turned off, and flexible identifiers are disabled. If the flexible identifiers are enabled for an Auth0 database connection, there is no option to disable the feature on the dashboard; however, it can be disabled via the management API.

The downside of this option is that the legacy database will remain the source of truth, and passwords will still be stored there.

Option 2

1. It is possible to fully customize the Classic Universal Login so that a user can enter a non-valid username, which is then sent to the custom database scripts.
2. The custom database scripts would validate the credentials against the legacy database.
3. If the credentials are correct, the script returns a username like newuser for example.  This new identifier would then be appended to a unique random string (e.g., "newuser-RANDOM-STRING").
4. Implement an Action to check the username. If the username has "newuser" in it, force a redirect to a page where the user is notified to change their username with the allowed characters.
5. The user enters their new username, the application updates the username via the Management API, and then redirects the user to the login entry point to re-authenticate, since updating the username invalidates the Auth0 session.

Option 3

If it is possible to have users log in only with their email addresses, the legacy user names could be stored in the app_metadata field of the user profile during import in the custom database script. This can help insert the user's legacy username into a custom claim in the Access or ID Token. With that addition, the username can still be used in downstream apps. The only side effect is that users cannot log in with their username and must log in solely with their email.