I don’t see another way tbh, maybe someone else can chime in. In theory if you can decrypt the passwords in your MySQL database then you can feed them into Fauna but in many production systems we are unable to decrypt the passwords for good reasons. In that case I don’t see another way then to reset the passwords and ask the user to fill it in.
In that case, Fauna is not storing your users but Auth0 is. Which means that you indeed have to go through it again. In Fauna a password can not be retrieved. If you are confident that you can store them securely and find a way that makes sense to decrypt them you could opt to store them externally and verify the password outside of Fauna in this intermediate phase to ensure that you can easily switch to Auth0 afterwards (you can still make tokens directly after verifying the password instead of using Login()). In that case you are responsible for storing the passwords securely and verifying the passwords upon login.
Non ideal workaround 1: I don’t think you can get around the password reset but when moving to third-party auth, you could present it to users in a way that provides them benefit. In essence, you have legacy-auth users and third-party-auth users and give the user the choice to update when they would like to start using social sign on features in which case you redirect them through the password flow.
Non ideal workaround 2: When users log in, you have their password in the application itself. You could silently upgrade users once they log in in the legacy system.
Looking further, it seems that some services (such as Auth0) offer a way to import password hashes. I’m looking internally to options to make such a transition smoother in the future.
