Hello, I’m trying to understand how to achieve a reset password without using the universal login.
I have a couple of questions about it:
-
I would like my users to receive a reset password e-mail with a link which redirects to my reset-password page and it seems not possible since it is not documented here or it can’t be set in the Dashboard => Emails => Email Templates => Change Password options.
-
As soon as the 1) is reached I believe that the link in the e-mail body should include some kind of token issued by auth0 which can be verified by my back-end. In case of success of the token validation my back-end will interact with auth0 in order to set the new password for the user.
How can I achieve this flow which I believe is a very common one using auth0 feature? I already looked at the various documentation pages but they are really confusing.
Thanks in advance.
Hi @andrea.speziale
Your subject is confusing, since the “reset password” page is one of the pages in the Universal Login Page set.
I think what you are asking is “:How do I start the reset password flow myself, instead of the user clicking ‘forgot password’ on the login page?”, correct?
You can invoke the flow with this API endpoint: Authentication API Explorer
You can generate the link and email it yourself using this endpoint: Auth0 Management API v2
John
Hi @john.gateley
The first endpoint proposed by you will trigger the password reset for a specific user and it’s ok. The fact is that the link in the e-mail is redirecting to the auth0 reset password page, the one that can be found and customized in the auth0 dashboard under the Universal Login tab.
But what if I would like to redirect the user to my FE page where the user will prompt the new password?
I also believe that to the upper described link a token should be added so as soon as the new password is typed and submitted to my back-end I can evaluate that token and eventually update the password interacting with auth0
Is it more clear?
Thanks in advance
Hi @andrea.speziale
If you want the user to enter their new password on your page, then you can update the user via Auth0’s management API:
https://auth0.com/docs/api/management/v2?_ga=2.7449531.886009023.1611066752-1115526131.1581090409#!/Users/patch_users_by_id
Be very careful with this. You have to consider many things, not just the token, when implementing the password reset flow yourself. Unless there is a REALLY compelling reason to do this, use Auth0’s built in flow.
John
Hi @john.gateley my understanding based on your answer is that there are no really alternatives to the auth0 built in reset-password flow.
For “built in reset-password flow” I mean the usage of the “Universal Login => Password reset” in order to let the user insert the new credentials.
Is my understanding correct?
Plus I don’t really get your concern about my described flow.
I’ll try to summarize it again to confirm that we are on the same page:
- the user land on my very own login page and finds the link of the “forgot password”
- clicking the “forgot password” link the user will be redirect to a page containing an input form
- the user will insert the e-mail and will submit the form
- an e-mail is sent to the user with a link to my very own “reset password” page (something like: https://mypage.com/xyz?token=xyz)
- the user will enter the new credential and submit a post request to me along with the token which legitimates the update of the password
- the user login with the new password
What am I missing and what can I achieve with Auth0?
My hope was that auth0 fits in the upper bullet points with the send of the email to the user with a token issued by auth0 which my back-end can validate and can change the user password accordingly with the instantiated management client
Hi @andrea.speziale
As I said, there is an alternative, you PATCH the user with the new password, and you can build your own flow around that.
My question is why are you building your own flow? It looks like it duplicates Auth0’s flow without adding anything. Flows are hard to design, and I again urge a full security analysis of your flow if you do this. For example, you mention nothing about password hygiene in your steps: how are you handling the password to ensure it is never logged or leaked from your application.
John
Thanks @john.gateley for your inputs.
As you mentioned my plan was to actually PATCH the user using the auth0 management client on the BE side as my very last step.
The upper very last step would just happen as soon as I’m able to verify a token which I believed auth0 was capable to generate and send in the reset-password email body along with a settable link.
Since:
- I’ve developed a Resource Owner Password flow on my BE side (so I’m actually implementing what auth0 calls “Embedded Login”) using auth0 APIs
- I’ve developed my very own FE along with my input forms for signup and login which interact with my BE
I don’t really like the idea of having half of the flows (login and signup) under my control using auth0 APIs and the reset-password flow on the auth0 dashboard.
How can I eventually setup “Universal Login => Reset Password” customized page to a specific domain like: .xyz Domain Names | Join Generation XYZ?
Thanks in advance
Andrea
Hi @andrea.speziale
There is no way to tell Auth0 to use a different page for the reset password page (or any ULP for that matter).
You can use the tenant CNAME feature to get a more friendly URL for that page.
ROPG is not recommended. As noted in this thread you take on additional risks when using it, and also lose capabilities (SSO, centralized login code for all apps etc.).
John
Thanks again!
At this point, speaking about the reset-password flow, my understanding is that there is no way to achieve what (and how) I would like to achieve.
I believe and understand that auth0 as a product push for the usage of the Universal Login and all the stuff around it but in my opinion it creates a strong lock-in to the product itself
In my vision auth0 APIs (REST endpoints) should give to its users and so customers the freedom to create an abstract layer over it being more flexible in case of changes.
Since it seems that the available APIs are not really covering some of the most common possibilities/flows an hypothetical auth0 user/customer who wants to use the APIs as mentioned above will unlikely need to manage the flows half on its systems and half on the auth0 dashboard