Update password vs Reset Password

When it comes to change password, traditionally update password and reset password are two seperate ways. Reset is more when user forgets their existing password and update is when they remember the password, they login to the app and then want to rotate it.

Going through documentation and a lot of communitity articles we couldn’t find a way to implement the later, update password. The available options mostly we find are

  1. Send a reset password link directly from Auth0 in an email using authentication APIs
  2. Get a change password ticket using management API and send it from app
  3. Directly patch user with new password
  4. Update from admin console

We would liek to understand If there’s a way to redirect user to Auth0 UI that can handle collection of new password and prompt them to provide their current password for security reasons.

If this is not a supported option then we could implement update password screen within our app and patch the user with management API. But the main challenge takin this approach woudl be handling errors related to password policies and esp., history policy.

Does either of the options provide an interactive password strength checkmark?

Hi @karuissobusy,

Welcome back to the Auth0 Community!

I understand that you would like to know what options do Auth0 provide when it comes to validating users’ password before getting it changed.

Even though there is no out-of-the-box method of achieving this use case, I believe you can opt between two primary architectural paths.

You can implement a ‘Step-Up Authentication’ path:

  1. When the user clicks “Change Password” inside your app, redirect them to Auth0 Universal Login using the OIDC parameter prompt=login. This forces the user to re-verify their identity (providing their current password) before proceeding

  2. Once the user returns to your app successfully authenticated, your backend generates a Change Password ticket via the Management API

  3. You then redirect the user to the ticket URL, where the Auth0-hosted UI securely handles the collection of the new password

  • Does this provide an interactive password strength checkmark? Yes. The Auth0-hosted password reset page (whether via New Universal Login or the Classic Auth0ChangePassword widget) has a built-in interactive password strength indicator. It evaluates the connection’s password policy (length, complexity, history) in real-time as the user types, displaying green checkmarks for met criteria.

Otherwise, if you prefer to keep the user entirely inside your application’s UI to avoid disruptive redirects, you can build a custom form that collects the information from your end and follow the brief workaround description listed under this KBA - Verify Current Password Before Changing to New One.

This can be achieved by following these 2 steps:

  1. Your backend can verify the current password using the Resource Owner Password Grant (ROPG) (making a /oauth/token call with the user’s username and current password).

  2. If the current password is valid. you can patch the new password in your backend via the Management API (PATCH /api/v2/users/{id}) with the new password

If you choose this later option however, there are a few major drawbacks since there is no out of the box solution for handling password strength and history policy errors, so you must explicitly manage this checks and exceptions from your end. While you can hardcode standard complexity checks (like length, casing, and numbers) to mirror your Auth0 policy, it is impossible to evaluate the Password History Policy from your end because your app’s code has no access to the user’s previously used passwords. The user will only find out if they violated the history policy after submitting the form and receiving a generic password strength error from your backend.

In conclusion, I would recommend taking the first approach, and if you would to, you can also submit a Product Feedback since other might be interested in this option as well.

I hope this helps and if you have further questions on the matter please let me know.
Best regards,
Remus