Password reset confirmation mail

Get Help
,
1

I created an Action that sends a confirmation email after a password change. I have multiple applications that share the same database connection.

The email contains contact information that users can reach out to if they did not initiate the password change themselves. Since each application has a different support contact, I need to determine which application triggered the password reset.

Unfortunately, the event object in the Post Change Password Action does not contain the application ID.

Is there another way to determine within the Action which application initiated the password reset?

3

Hi @Alois.Goeth

Currently, the client_id (Application ID) is not natively available in the event object of the Post Change Password trigger. Because the user completes the password change on a centralized Auth0-hosted page, the context of the original application that requested the reset is stripped from the transaction by the time the user actually clicks “Save” and triggers your Action.

Common causes for this type of issue:

  1. Event object limitations — The Post Change Password Action trigger may not expose the application context because password changes can be initiated through multiple channels (user-initiated via login page, admin-initiated via Dashboard, API-initiated), and not all channels have application context available.

  2. Shared database connection design — When multiple applications share a single database connection, the Auth0 platform may not track which application initiated the password change at the action execution level, because the action runs at the connection level rather than the application level.

  3. Alternative data sources — You may need to use Auth0 Management API calls within the action to look up the user’s recent login history or session context to infer which application was used, but this approach is indirect and may not work for all password change scenarios.

Since you cannot directly pull the application ID from the event object, you have two primary workarounds to solve this problem, depending on how much you want to change your existing architecture.

[RECOMMENDED WORKAROUNDS]

OPTION 1

Instead of sending the email immediately when the password is changed, you can delay the email by a few seconds and send it during the user’s next login. Because users almost always log in immediately after changing their password, this provides a seamless experience, and the Post-Login Action does have access to the client_id.

  1. Modify your Post Change Password Action: Instead of sending an email, use the Management API to flag the user’s metadata:

    // Post Change Password Action
exports.onExecutePostChangePassword = async (event, api) => {
  // Use Management API to set app_metadata.password_just_changed = true
};

  2. Create a Post-Login Action: This Action will check for the flag, send the email using the available event.client.client_id, and then clear the flag.

    // Post-Login Action
exports.onExecutePostLogin = async (event, api) => {
  if (event.user.app_metadata && event.user.app_metadata.password_just_changed) {
    const appId = event.client.client_id;
    
    // 1. Determine your support contacts based on appId
    // 2. Send your custom email via SendGrid, AWS SES, etc.
    
    // 3. Clear the flag using the Management API so it doesn't send again
  }
};

OPTION 2

If business requirements dictate that the email must be sent the exact millisecond the password is changed (even if they don’t log in), you must pass the application context through the user’s profile before the reset happens.

  1. Intercept the Reset Request: Instead of letting users use the default “Forgot Password” link on the Universal Login widget, you must build a “Forgot Password” form on your own application’s frontend.

  2. Tag the User: When the user submits their email, your backend uses the Auth0 Management API to update the user’s app_metadata with the source application (e.g., app_metadata.last_reset_app = "APP_A_ID").

  3. Trigger the Reset: Your backend then calls the Auth0 Authentication API (POST /dbconnections/change_password) to send the Auth0 reset link to the user.

  4. Update your Action: When the user finishes the reset, your Post Change Password Action checks event.user.app_metadata.last_reset_app. It uses this value to generate the correct email contact info, sends the email, and then uses the Management API to delete the last_reset_app flag.

If you want to avoid writing custom backend logic to intercept password resets, Option1 is the standard industry approach for bypassing this Auth0 limitation. It shifts the execution to the Post-Login flow where the full event.client object is completely populated` context is readily available.

Kind Regards,
Nik