Silent migration and password breach

Get Help
,
1

I migrate users from ADB2C to Auth0. I added getuser and login script to the database connection that return a user object with app_metatdata that contain the settings from the legacy IDP (ADB2C)
The following cases work as expected:

  • User logs in with credentials fron legacy IDP
  • User resets password as he has forgotten the password from the legacy IDP-

In both cases the user is created with the corresponding app_metadata.
Password breach is enabled on our tenant as it is mandatory in our company.
So the third option is:
User wants to log in. He gets a error message (Please reset password..) as he is using a breached password.
After password reset the user is created but the app_metadata are empty.

In the working cases “getuser” script is executed several times.
But in the case with the breached password “getuser” is executet only once (during the firts login attempt) but it is not executed during the password change.

We use password change with code. (if that is important)

To sum up:

  • When i reset the Passwort the migration works as expected
  • When i first try to log in with a breached password and reset the password afterwards the second call of the “getuser” script is missing and therefore the app_metadata are missing.
3

Hi @Alois.Goeth

You are asking why the app_metadata from your legacy Azure AD B2C identity provider is missing for users who first attempted to log in with a breached password and then reset their password, even though the same flow works when the user resets the password first.

[Root Cause] On-demand migration calls the Get User script only when Auth0 has no user record for that email. In your breached-password path, the first login attempt is rejected before the user record is fully created, so the user record that exists after the reset is created from the reset path without the profile data returned by the first Get User call. Because the Get User script is not re-run for an existing record, the app_metadata never gets written. Your password change with a code does not trigger another Get User call for that record.

[Solution] Do not rely on the Get User script to supply app_metadata for users who hit the breached-password path. Instead, backfill those users once from your legacy data and make the post-login flow handle any remaining gaps.

  1. Identify the affected users. Query the Auth0 logs for pwd_leak events followed by a successful scp event for the same email, and list the users whose app_metadata is empty.
  2. Export the required attributes from Azure AD B2C for those users, including the values your app stores in app_metadata.
  3. Update each affected user through the Management API using PATCH /api/v2/users/{id} with an app_metadata object. Use a Machine-to-Machine application with the update:users scope for this call, and do not use a Single Page Application client, because it cannot request the client credentials grant.
  4. Add a post-login Action that checks whether app_metadata is empty for users who came through the legacy connection, and then fills it from the same source. This prevents the gap from recurring for future breached-password cases.
  5. Test with a test account that has a breached password. Confirm that app_metadata is populated after the reset and after the next login.

If the Get User script still does not run for a specific user after these steps, open a case with Auth0 Support so the team can verify the migration invocation in your tenant logs.

Please follow up if you need further assistance after reviewing the affected user list.

Kind Regards,
Nik

4

Hi Nik,

Thank you for your help.
Are there any other use cases where the user migration might not work as I expected?

Regards,

Alois