Once again I am absolutely stumped/confused as to why this super obvious issue isn’t addressed in 5+ different documentation pages around user import/migration from an existing legacy DB to auth0.
I’ve used both the import-users extension and bulk-import-user management API functionality (a real pain to setup!) to import a json file with my users into auth0. Both work, and seemingly perform the exact same function.
However, the obvious issue here is that since no passwords have been set for the users, how can they login? One would expect, upon first login of a user to be prompted to reset (set) their password via their email, but instead the login screen simply says “incorrect password” and the user is totally confused. Any advice on this would be great.
Edit:Doc here simply states: “Each affected user will need to reset their password when they log in the first time after the bulk import.”. Surely, in the interest of seamless UI and the fact that users won’t even know/care that they were migration to auth0, we cannot expect them to first attempt to login multiple times and finally resort to clicking on “reset” password? Why is Auth0 so much pain every step of the way
For our (where I work) own purposes, we try to use the on-demand migration when possible. When we have done bulk migrations we always precede the migration with an email campaign to let the users know what is happening (of course, probably 80+% of users don’t read the emails!)
A more active approach would be to write a script against the mgmt API to trigger password resets for your imported users. It would be helpful if suggested solutions like this were in the docs. I might add something to the bulk migration docs today if I have a chance.
In general, while Auth0 are always adding new functionality (the pending new authorization management feature, future new DA dashboard), more often than not they simply provide the tools (the API) and we (all of us using Auth0) build our own solutions with those. I like to think of Auth0 as “coding glue” sitting between our apps/APIs and our user repositories… fewer “polished finished products” but a great deal of flexibility in developing our own solutions.
That’s certainly a fair point of view - I don’t necessarily disagree, just wonder how a piece of SaaS goes through 11 major releases (Lock.js) without accounting for such basic end-user functionality. It basically means that it’s completely useless when paired with the importing of users and forces me to instead rely on the legacy-db-migration, which comes with its own quirks and caveats (you can’t ever turn off import and other nonsense).
Sometimes auth0’s offerings feel more like that of a startup MVP and less like they are thought through and polished from top to bottom.
@auth0@maxtor, I’ve also blocked with the same issue reported here. The password will not be stored in Auth0 database on bulk user import, and user is not aware that they need to reset the password. Hosted Login Page(HLP) is just displaying “WRONG USERNAME OR PASSWORD”. With this info user will not know, that they need to reset the password.
Did you get any response from Auth0 for this issue? Or, If you have found any solution for this issue, Would you please share here if it’s okay for you?
Advance thanks
I did not, see my previous reply above. I ended up having to use the legacy-db integration…which has worked fine so far.
Another approach here would be to use the management API and recursively trigger a PW reset for every user imported into Auth0 (hardly ideal since you’d likely want the transition to auth0 to be a seamless as possible, without having to notify user & force them to take an action, but it is another option…).
The only seamless migration option currently supported is automatic migration.
Bulk user import does not include a user’s password. Not seamless, but there are technical reasons for this. It would be nice if there was a trigger that automatically sent the user a password reset, or automatically asked them to reset their password, but no such solution exists today as far as I know. If you go this route I would suggest a multi-step communication plan to your users to let them know what is coming.
I have the exact same issue at the moment and will go the way to trigger a password change via https://auth0.com/docs/connections/database/password-change#use-the-authentication-api. The question here is why can’t I specify a redirect url here? With this solution the user will just receive an email with a password reset link and after he set/changed his password he is stuck on the lock widget.
An alternative would have been Auth0 Management API v2 where you can specify a recirect url, but here no email is triggered you just get the password reset link in the response.
Both methods are essentially useless for the case of letting the user initially set a password after bulk import.
Ughh… been digging around for how to handle this and finally found this topic and seems it can’t be done cleanly. Auth0 docs and quick starts get you like 85% of the way there – that last 15% is a real pain it seems
Figured a simple scenario of sending every user a “hey! you need to reset your password, here’s the link” email would be easy enough but… it’s not? is that what I’m gathering?
AFAIK it is still the case that import does not trigger a password reset email. It is now possible to import existing passwords as long as they are bcrypt hashed:
Auth0 supports hashed passwords that use bcrypt $2a$ and $2b$ with 10 saltRounds
If you don’t have existing passwords hashed as above, on-demand migration still offers the most seamless migration offering. Alternatively, after bulk importing you can use the authentication API to send change password emails:
I have found a workaround that seems to work for my situation.
I’ve had automatic migration (Configure Automatic Migration from Your Database) running for 7 months and got to a point where I wanted to cut it off. I thought I needed to do a bulk import of my unmigrated users, but then ran into the issue described in this discussion – poor user experience for unmigrated users. I didn’t want to mass-email them to tell them to reset their passwords (they are disengaged users anyway since they haven’t logged in in 7 months); I wanted a user to be told to reset their password the next time they tried to log in.
In the automatic migration phase my login script checked the email / password combination in my legacy database. I just changed that to instead check only if the email exists in my legacy database and if so, return a new ValidationError('force_password_reset'). (Note that the login script only gets executed when the email doesn’t exist in your Auth0 database.) Then in my Lock implementation, if I get this validation error, I display an error message to the user "It's been a while since we've seen you, so you must reset your password. Please click "Forgot your password?" to continue."
This approach has the added benefit over bulk import of not importing a bunch of users that might never log in in the future.
