Hello experts,
I am trying to implement a use-case where a user forgot his password and clicks on “password reset” on our website. Next thing, he enters his email address and we’re using the
https://xxxxxxxxxx.eu.auth0.com/dbconnections/change_password
endpoint to send an email with a verify link to him. This works and he receives the email. The email contains a link back to our website with a ticket in the query parameter, like so:
https://our-website.com/#/auth/lo/reset?ticket=qYeP99X5rraPoHasd5NLI3qhScBy1926#
Upon clicking this link, the user gets to our website and is prompted to enter his email and come up with a new password. Therefore now we have:
- a ticket
- the email address
- a new password
However, I cannot find any documentation what to do with these pieces of information. I would have assumed there is an auth0 api endpoint that lets me change the password using the ticket as a one-time-valid authorization. Can someone push me into the right direction as to how to proceed from there?
Thanks,
Christian
I’m likely missing something as I don’t understand how you got from calling /dbconnections/change_password
to having an email with a link to your own application. A quick test show that the email sent to the end-user would be in this format https://[account].auth0.com/lo/reset?ticket=i4Wf...#
which is associated with the hosted reset password page. Can you provide additional information about this point?
Yes, as far as I can see it is designed so that you will get redirected to https://[account].auth0.com/… , but this is for our usecase not acceptable, the user needs to stay on our website and not be redirected to auth0.com. That’s why in the email template, we changed this url to point to our website. I was assuming there is an api call that the hosted website was using to reset the password, but I cannot find the documentation. What I would like to do is to perform that reset-request against the api myself on our website rather than using the hosted page.
As you mentioned the endpoint that allows to receive a reset password ticket is designed only for internal consumption as part of the reset password hosted page; the page in question already allows some degree of customization and I can let you know informally that we are considering augmenting the customization capabilities for that page in order to provide even more flexibility. However, the ticket would still need to be used in that hosted page.
Technically, if you’re willing to venture far enough you may reach the conclusion that there may be a way to hack your way around it and still be able to programmatically call the ticket-based endpoint, however, I’m calling this out because you could reach the conclusion yourself and also because I want to reiterate that you would be in unsupported territory where any change to the internal endpoint could break your process.
At this time, if you want full control over the management of end-user passwords then you can do so by calling into the Management API and updating the user directly, however, this implies you’ll have to own the whole flow and that you’re not going to be able to reuse the built-in reset password tickets.
Thanks for the quick reply. I just wanted to make sure I’m not missing anything. I wont try to use the internal endpoint with the ticket. Instead I’ll set up a password-reset feature using the management api.
Thanks.