Validate Current Password Before Allowing Password Change (User & Admin Flow)

Description

We are using Auth0 as our authentication provider for both users and admins.

We want to implement a secure password change flow with the following logic:


Required Flow

  1. User/Admin enters:

    • Current password

    • New password

  2. System should:

    • Verify whether the current password is correct

    • If correct → allow password update

    • If incorrect → show error and do not update password

  3. If the user does not remember the current password →
    they should use the standard “Forgot Password” flow.


Current Issue

We are unable to validate the current password before allowing the password update.

Since passwords are hashed and managed by Auth0, we do not have a direct way to:

  • Check whether the entered current password is correct

  • Without performing a full login flow


Questions

  1. What is the recommended approach in Auth0 to verify a user’s current password before allowing a password change?

  2. Should we:

    • Use a step-up reauthentication flow (prompt=login) before showing the change password form?

    • Or call the /oauth/token endpoint with the Resource Owner Password Grant (ROPG) to validate the current password?

  3. What is the secure and recommended method for this use case for both:

    • Regular users

    • Admin users

  4. Are there any best practices or security considerations we should follow for this flow?

Hi @nihalm5930,

Welcome to the Auth0 Community!

Auth0 does not have an out-of-the-box method of achieving this use case, however both of the options you have mentioned above can be considered here.

For verifying a user’s current password before an update, the recommended approach is to implement a re-authentication or step-up flow. This ensures that the user is currently present and authorized to perform a sensitive account change. For regular users, this usually involves a simple password re-entry, while admin users should be required to complete a multi-factor authentication (MFA) challenge to mitigate the risk of account takeover.

If you choose to use a step-up re-authentication flow with the prompt=login parameter, you are leveraging the most secure OIDC-native method. This approach is highly secure because your application never handles the user’s current plain-text credentials, as Auth0 manages the entire validation process on its hosted pages. However, the user experience suffers slightly because it requires a full redirect away from your application to the Auth0 Universal Login page and back, which can feel disruptive to a seamless in-app journey.

If you opt for the Resource Owner Password Grant (ROPG) via the /oauth/token endpoint, your backend collects the current password to “test” it against Auth0. This provides a superior user experience because it allows the user to stay entirely within your application’s custom UI without redirects. The significant security drawback is that your application infrastructure temporarily touches the user’s current password, increasing the risk of credential exposure. This is presented as an option in this article as well - Verify Current Password Before Changing to New One.

To ensure the security of both regular and admin users, you should implement a multi-layered defense strategy during the password change process. You must apply strict rate limiting on your password-validation endpoint to prevent malicious actors from using the form to brute-force current passwords, which protects your users from credential stuffing. It is also essential to trigger an automated email notification to the user immediately after any successful change, as this serves as a critical alert in case of an unauthorized account takeover. For admins specifically, a password check alone could be insufficient, so you should also enforce an MFA challenge, since a password alone is not a sufficient safeguard for accounts with elevated access to your system’s infrastructure.

I hope this helps and if you have further questions please let me know!
Kind regards,
Remus