If I simply change their email upon their request, the new email can be something different from what they think they own. (e.g. mis-typing can happen abc@example.com => abd@example.com)
Resulting they don’t get emails from us, and/or they can’t login with the new email address (trys to login with abc@example.com when it’s registered with abd@example.com)
If I don’t ask them for their password, somebody who gets access to the website can just take over the account. (e.g. people don’t always intentionally logout every time they leave the computer - may only just close the browser)
The steps would be
somebody opens the website where its credentials are still valid without password
goes to “change your email” and finish verifying the email
goes to the login page, and click “forgot your password” to reset the password
As far as I searched, Auth0.com doesn’t provide this kind of mechanisms out of the box.
The parts I am having trouble trying to figure out are …
entering a new email that can later link to the login user
letting them type in correct password before adding a new email
Autho0.com itself doesn’t let users to change their email at all. Instead, it asks the user to add a new administrator, and delete the old one … so is this even possible with Auth0?
I found these related posts, but they don’t cover my scenario.
entering a new email that can later link to the login user
For this one, maybe I can simply send a random ID to the new email a user enters. When the user enters the same ID on the website, the server can simply use PATCH /api/v2/users/{id} to update the email? I guess.
user clicks “change your email”
browser shows an input for a new email
user enters a new email
browser generates ID, and send a signal to the server, so it sends an email with the ID
user opens the email and find the ID
user comes back to the browser and enters the ID
when the ID matches, send a signal to the server so it changes the user’s email
But I am still left with the password protection onto actually changing the email.
Hello,
Given that email address is a unique identifier of a user & providing an ability to change the email-address via self-service should be considered a very sensitive operation, so care must be taken to verify the user’s ownership to his current logged-in account along with the ownership to his new email address before changing the user’s email is important.
In order to verify user’s current ownership, this can be achieved by having the user go through step-up aka prompting a user to re-enter password or challenge with MFA (if already enrolled).
In order to verify the ownership of the new email address, this can be achieved by sending an OTP code/verification link to the new email address. Auth0 passwordless email feature can be used to perform this.
Please do note that changing an user’s email will terminate all SSO sessions of the user for security reasons, so it is important to prompt the user to re-enter their credentials using new email address/password.
Depending on the UX experience that you’re looking for, there might be few ways to do implement this. For a generic detailed design, please see this github repo. In case, more guidance is needed, Auth0 Professional Services can definitely assist in designing/implementing an architecture to suit your UX needs along with aligning to security best practices.
@praveen.addepally , I have a problem with implementing according to your answer.
After the second step (Passwordless Authentication with Email) when user successfully click on verification link in email and athenticate to application, Auth0 creates new user with new email.
So calling endpoint PATCH /api/v2/users/{id} to update users email results with exception that email already exists.
Could you please advise how to deal with it?
Also, it is normal workflow that if new email is not verified yet, user normally can use the old one.
And the steps you provided sounds like a weird workaround and normally this functionality should be available out-of-the-box
@ale.spodin - Reg your question, yes a brand new user will be created under the passwordless email connection with the new email. Please note that the email address is unique within a connection & if you are calling the PATCH /api/v2/users/{id} with the user_id of the email/password user, then ideally you shouldn’t receive the “user already existing error”. One scenario I could think of where you might get this error is if you already have a user with the new email in the email/password connection.
Agreed, it would have been nice to have this feature supported out of the box. I checked internally & I do see feature requests on this but unfortunately, they did not make it to the roadmap compared to other requests.
