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 <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" /> in LocalAccountWritePasswordChangeUsingObjectId technical profile, it works, user is redirected to change password page, but in this case old password is not getting validated which is wrong. So what is the reason for this behavior?

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="login-NonInteractive">
      <DisplayName>Local Account SignIn</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="ProviderName">https://sts.windows.net/</Item>
        <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
        <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
        <Item Key="response_types">id_token</Item>
        <Item Key="response_mode">query</Item>
        <Item Key="scope">email openid</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="HttpBinding">POST</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" Required="true" />
        <InputClaim ClaimTypeReferenceId="password" Required="true" />
        <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" AlwaysUseDefaultValue="true" />
        <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" AlwaysUseDefaultValue="true" />
        <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Local Account SignIn Password Change</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="login-NonInteractive-PasswordChange">
      <DisplayName>Local Account SignIn Password Change</DisplayName>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="oldPassword" PartnerClaimType="password" Required="true" />
      </InputClaims>
      <IncludeTechnicalProfile ReferenceId="login-NonInteractive" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Local Account Password Change</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LocalAccountWritePasswordChangeUsingObjectId">
      <DisplayName>Change password (username)</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="objectId" />
        <InputClaim ClaimTypeReferenceId="state" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="oldPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="state" DefaultValue="change_password" AlwaysUseDefaultValue="true"/>
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" />
        <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

journey

<UserJourney Id="PasswordChange">
    <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.signuporsignin">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection TargetClaimsExchangeId="LocalAccountSigninEmailExchange" />
            </ClaimsProviderSelections>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordChangeUsingObjectId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
    <ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>

Navya 15,145 Reputation points Microsoft Vendor

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

Share via

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

Your answer