Azure B2C custom policy self asserted change password skips change password screen when user has active session

Question

Azure B2C custom policy self asserted change password skips change password screen when user has active session

Mariam Harutyunyan 0

I have implemented self asserted password change flow in my custom policies according to the instructions described in https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-password-change-policy?pivots=b2c-custom-policy. However when running the flow it works as expected when user is not logged in, it presents login screen and after login goes to the change password screen but when user is already logged in and has active session and I enter the url in browser (same tab) to run the change password flow it does not show the change password screen, instead /authorize request returns HTTP 302 code and a code in url like in regular authorization flow. The issue is when I comment out the `

Navya 19,795 Reputation points Microsoft External Staff Moderator

2025-01-31T14:44:51.7433333+00:00

Hi @Mariam Harutyunyan

Thank you for posting this in Microsoft Q&A.

I understand that you are implementing a password change using custom policies in Azure Active Directory B2C but have noticed that this option is skipped for users with an active session.

The password change flow involves the following steps:

1.The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step.

2.In the "Old Password" field, the user verifies their old password. In the "New Password" field, they create and confirm their new password.

In the scenario where the user is already logged in, the flow tries to trigger an authorization request, which usually redirects the user to an authorization or consent page. However, for a password change, you're looking to bypass that authorization step and go directly to the password change screen. The issue lies in the <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" /> within the LocalAccountWritePasswordChangeUsingObjectId technical profile. This profile references the non-interactive password change flow, which typically expects an active session (and thus tries to trigger the /authorize flow as if it's a standard authentication request).

When you comment out the <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" /> in the LocalAccountWritePasswordChangeUsingObjectId technical profile, the flow doesn't attempt to validate the password via the login flow. It skips the validation technical profile, which allows the old password to be accepted, even if it was incorrect.

Hope this helps. Do let us know if you any further queries.

Thanks,

Navya.
Mariam Harutyunyan 0 Reputation points

2025-02-02T20:52:23.09+00:00
Hi Navya,

Thanks but it doesn't really help, I wan't to understand how to solve this issue. You mentioned that The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step., okay doesn't this mean that if user is already logged in thus has active session it should skip the authorization part and redirect to the password change screen?

I don't understand why ValidationTechnicalProfile should affect the flow behavior like this. How can I achieve the following behavior?

Already signed in user who has active session triggers change password flow

As there is an active session user is redirected to change password screen

User enters passwords and submits the request

The flow validates old password and changes it
Navya 19,795 Reputation points Microsoft External Staff Moderator

2025-02-12T05:45:03.7566667+00:00

Hi @Mariam Harutyunyan

Thank you for following up on this.

When a user is already logged in and initiates the password change flow, Azure AD B2C attempts to bypass the login step (since the user is already authenticated) and proceed directly to the next step in the journey. The issue arises from how the Azure AD B2C flow manages the session and authentication state.

It appears that Azure AD B2C is not recognizing the user's intent to change the password. Consequently, it triggers the authorization code flow instead of directly displaying the password change screen. The flow anticipates either a fresh login or an explicit password changes request, but B2C does not interpret the request as a "password change" action. Could you please try forcing a Password Change Flow for Logged-in Users?

Your answer

Navya 19,795 Reputation points Microsoft External Staff Moderator

2025-01-31T14:44:51.7433333+00:00

Hi @Mariam Harutyunyan

Thank you for posting this in Microsoft Q&A.

I understand that you are implementing a password change using custom policies in Azure Active Directory B2C but have noticed that this option is skipped for users with an active session.

The password change flow involves the following steps:

1.The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step.

2.In the "Old Password" field, the user verifies their old password. In the "New Password" field, they create and confirm their new password.

In the scenario where the user is already logged in, the flow tries to trigger an authorization request, which usually redirects the user to an authorization or consent page. However, for a password change, you're looking to bypass that authorization step and go directly to the password change screen. The issue lies in the <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" /> within the LocalAccountWritePasswordChangeUsingObjectId technical profile. This profile references the non-interactive password change flow, which typically expects an active session (and thus tries to trigger the /authorize flow as if it's a standard authentication request).

When you comment out the <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" /> in the LocalAccountWritePasswordChangeUsingObjectId technical profile, the flow doesn't attempt to validate the password via the login flow. It skips the validation technical profile, which allows the old password to be accepted, even if it was incorrect.

Hope this helps. Do let us know if you any further queries.

Thanks,

Navya.
Mariam Harutyunyan 0 Reputation points

2025-02-02T20:52:23.09+00:00

Hi Navya,

Thanks but it doesn't really help, I wan't to understand how to solve this issue. You mentioned that The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step., okay doesn't this mean that if user is already logged in thus has active session it should skip the authorization part and redirect to the password change screen?

I don't understand why ValidationTechnicalProfile should affect the flow behavior like this. How can I achieve the following behavior?

Already signed in user who has active session triggers change password flow

As there is an active session user is redirected to change password screen

User enters passwords and submits the request

The flow validates old password and changes it
Navya 19,795 Reputation points Microsoft External Staff Moderator

2025-02-12T05:45:03.7566667+00:00

Hi @Mariam Harutyunyan

Thank you for following up on this.

When a user is already logged in and initiates the password change flow, Azure AD B2C attempts to bypass the login step (since the user is already authenticated) and proceed directly to the next step in the journey. The issue arises from how the Azure AD B2C flow manages the session and authentication state.

It appears that Azure AD B2C is not recognizing the user's intent to change the password. Consequently, it triggers the authorization code flow instead of directly displaying the password change screen. The flow anticipates either a fresh login or an explicit password changes request, but B2C does not interpret the request as a "password change" action. Could you please try forcing a Password Change Flow for Logged-in Users?

Share via

Azure B2C custom policy self asserted change password skips change password screen when user has active session

Your answer