We are migrating our web application to Auth0 and we are wondering what is the best approach to create users.
We would like as much as possible to avoid the user being forced to fill 2 forms to register (i.e. our website form and the Auth0 form).
Ideally, we want to keep our custom registration form and call the Management API from our backend to create the user with the password entered by the user.
Looking at the Management API, I see that this is possible to create a user with a predefined password.
Also, when looking at the bulk import, I see that it is a best practice to either encrypt the password or to send a reset password link.
https://auth0.com/docs/users/bulk-user-imports
With that in mind,
-Why does the password needs to be encrypted with the bulk import, but not with the create user endpoint?
-Is it safe to send a password with the create user endpoint and should we send a reset link after the user was created?
At some point, we will also need to migrate existing users.
If the create user endpoint don’t required additional encryption for the password, could we implement a function that calls that endpoint for each existing user in our database (instead of using the bulk import endpoint)?
Hi @alexandre.gasse
There are two separate issues here: migrating your existing users and creating new users.
For creating new users, if you use the management API, they will NOT be logged in after registering and will have to reenter their password. It is NOT safe to set a password for them as you suggest. Bulk import is not applicable in this case.
You can add additional fields to the registration page. This is the best approach if it is possible.
For migrating existing users, the bulk import job is used. Normally you cannot get a password for an existing user, only the password hash. That is what bulk import expects
John
1 Like
Thanks for helping on this one John!
@john.gateley Thanks for your answer.
Given that we use a TLS 1.2 connection, can you explain why using the Auth0 API with a password would not be safe?
Customizing the registration page would not be a solution for us since the additional information that we are requesting are private information which should not be shared with Auth0.
We also have a requirement to show terms of usage and have a user agreement at registration time, which did not seem to be possible with Auth0.
When you set the password and then communicate the password to the user, that exposes a lot of surface area: the agent knows the password, it passes through several systems before arriving to the user. All of these are weaknesses.
Auth0 is very flexible: you can do usage and user agreement at registration time, or you can use redirect rules to do this (and gather the additional data, which then would not be part of Auth0).
John
1 Like
Hi again @john.gateley ,
Maybe I was not clear enough with my scenario.
We are not planning on choosing a password for the user.
The user will have a TLS connection to our website and fill the registration WITH a password.
That password is send with the form to our backend and then the backend would call the management API to create a user with its email and the chosen password.
So I’m wondering why would it be more secure for Auth0 to have sensitive information and call my API, rather than have my website calling the Auth0 API with a password (given that our backend will not keep that information)?
Thanks again
Just to make a follow up, we got an answer in the meantime from an Auth0 solution engineer saying that in our context, there is no risk with using the signup endpoint in the Authentication API to create a user (with the password).
https://auth0.com/docs/api/authentication#signup
That fills out our requirement since we won’t need to show the Auth0 registration form after our custom form and sensitive information will stay on our side.
Thanks for sharing that with the rest of community!