Is it possible to migrate from a magic link to a username/password login?

Hi @louh,

1 & 2.)If you are using Lock (Classic Universal Login), it can only be configured for either Passwordless or Database type connections, not both at the same time unfortunately.

You could workaround this to an extent by adding conditional logic to your hosted login page to show a “Lock” or “Passwordless Lock” widget based on the connection parameter sent in the /authorize request, or possibly a custom querystring parameter.
The downside is you would need to a way to figure out what method the user wanted to use before firing the /authorize request for this to work. This could be a couple different login buttons in your app or some other means of picking and sending the user with the right parameters to /authorize

Alternatively, you could create a custom login form which can accept both, using Auth0.js or even directly using the Authentication API for a “roll your own auth” (obviously this would require a lot more work on your side than using Lock).

Either way, a passwordless account would be seen as separate to a normal database account, (or any other connection type for that matter), so they would need to “sign up” again to set a password. You could however link the two accounts afterwards though to bring the two profiles together:

3.) Regarding information on your system, this can be kept as is if you prefer, you would just need to have a map between the Auth0 user_id and your internal resources, adding a password just means Auth0 stores the password hash and email/username for you. The only snag is if you require any additional information for authentication authorization purposes, in which case it is best to store that information in Auth0 for best performance so it is easier to access in rules, RBAC policies etc. on the Auth0 side.

4.) There isn’t an API for this unfortunately, you would need to create a custom script that could work this out based on the user profile via the Management API, but I wouldn’t recommend going down that route as this would almost definitely cause problems with rate limits on the Management API if it is fired before every login attempt.