Azure AD B2C Custom policy - translations encoding issue

Question

Azure AD B2C Custom policy - translations encoding issue

Teun Dozeman 5

Hi. We have Azure AD B2C configured with custom policies, including custom email verification.

The email verification part includes a step for verifying the code that is send to the users their email. After the code verification has been done a quick load(based on page getting some sort of gradiant overlay), the set password screen appears. But from this step all of a sudden their is an encoding issue with the ä character:

User's image

I've tried updating the template versions, but am still stuck after quite a lot of trial and error

Anyone an idea how to resolve this?

Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2023-02-21T04:34:18.34+00:00

@Teun Dozeman Apologies for the delay in reviewing this post, let me research on this query and revert back.
Teun Dozeman 5 Reputation points

2023-02-23T15:23:07.1933333+00:00

@Givary-MSFT Already had time to take a look? If I need to provide more information, let me know.
Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2023-02-24T06:54:36.4566667+00:00

@Teun Dozeman Discussed your scenario within my team and we used user flow in our lab for your scenario and can see the below page

Would like to understand more details about the configuration at your end what kind of policy you have implemented whether user flow or custom policy, if you can share screenshot, if possible, to investigate this further.

Teun Dozeman 5

@Givary-MSFT It is a custom policy, we have an angular application and e use the @azure/msal-browser package to open an authentication window with b2c scope: user_impersantion. If it test the scope manual with https://jwt.ms as reply URL I do also get a page with the custom provided theme, but the flow of creating an account is a little bit different. It looks more like the screenshot you provided.

But if I open the flow from the application, I first come to a URL with this structure:

https://(myb2c).b2clogin.com/(tenant-id)/b2c_1a_signinup/oauth2/v2.0/authorize?client_id=

If you press on register, then the URL changes to this:

https://(myb2c).b2clogin.com/(tenant-id)/B2C_1A_SignInUp/api/CombinedSigninAndSignup/unified?local=signup&csrf_token=

This register page looks like this:

User's image

On this page after filling in the email, you will receive a verification code, and if the code is valid, a next step where you can click "next" and then the page will come with the encoding issue. If I look at the custom policy, this is the User Journey:

<UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
   
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- This step reads any user attributes that we may not have received when in the token. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
 
        <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

For password reset, we also have the same encoding issue with this User Journey:

<UserJourney Id="PasswordReset">  <OrchestrationSteps>    <OrchestrationStep Order="1" Type="ClaimsExchange">      <ClaimsExchanges>        <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />      </ClaimsExchanges>    </OrchestrationStep>    <OrchestrationStep Order="2" Type="ClaimsExchange">      <ClaimsExchanges>        <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />      </ClaimsExchanges>    </OrchestrationStep>    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />  </OrchestrationSteps>  <ClientDefinition ReferenceId="DefaultWeb" /></UserJourney>

Teun Dozeman 5 Reputation points

2023-03-10T11:44:41.61+00:00

@Givary-MSFT Already had time to take a look?
Teun Dozeman 5 Reputation points

2023-03-28T13:36:57.1133333+00:00

@Givary-MSFT Did you had time to look into this problem? do i need to provide more information?