I was wondering, if any additional updates have been made regarding this discussion:
The main goal our back-end API needs to achieve, is not to send a verification link to the end-user which just signed up, unless the user has been created both inside the Auth0, as well as inside our application database.
One way to do it would be to have a custom front-end signup page where instead of signing up to the Auth0 directly, our front-end would contact our custom back-end API, which would be responsible for creating the Auth0 user (via Management API), as well as the database user, and then trigger the verification email trasmission (again via Management API).
However, we would like to avoid it, and instead, would like to use the Universal login page provided by Auth0 (of course, customized according to the visual identity of our app), so is there a way to avoid the transmission of the verification link in that sense?
I don’t see any developments on this. It looks like the strategy you described could be a solution. You could still use universal login, but would want to disable signups for the widget.
We would like to avoid using a completely custom signup form, since then we would need to be completely responsible for creating both Auth0 user, as well as application database user (in further text will be abbreviated as ADBU), but also tackle other security measures since it’s a custom public signup, and would prefer to use the Auth0 universal page if possible.
In case we are going with the universal login/signup Auth0 page, a POST request could then possibly be issued from our front-end to our back-end to create the ADBU after the successful Auth0 public signup (on callback). However, if anything during this process fails, there could be a scenario where there is e.g. only an Auth0 user created after a successful signup, but no ADBU (because of any exception on our back-end happening during the process of creating the ADBU triggered from the front-end after the successful Auth0 signup).
Would you have any suggestions on when would be a good time to create the actual ADBU in the process?
You can create the user on your side (your database) when they are first directed back to your application after signup. You can look at the sub claim in the token as the unique identifier, and if it doesn’t exist, create a user with that ID.