Azure Active Directory B2C Custom Policy duplicate users

Question

Hello friends :)

I have an Azure AD B2C tenant with a User Flow (Sign up and sign in) configured with Local Accounts and with Microsoft Account Identity provider. It's works perfectly.

Now I created an custom Sign up and sign in with Identity Experience Framework also using Local Accounts and with Microsoft Account Identity provider. It's works but there are two strange things.

1. When I run the flow, the Microsoft Account button not show the Microsoft Icon
2. If I have not account on my tenant and I login using the User Flow with Microsoft Identity provider, the user is registered correctly with the Microsoft Type associated, but if I access the system again using my custom Sign Up using the same Microsoft Identity provider, the user is created again further without the Microsoft Type associated.

I have followed the Azure documentation meticulously. Can someone tell me if there is any more to do? I think point 2 is the most important. Authentication works correctly, this should detect that the account already exists and that it is of type Microsoft Account not "Other".

Thanks for our time.

75870-xxxonmicrosoftcom-b2c-1a-trustframeworkextensions.xml75931-xxxonmicrosoftcom-b2c-1a-signup-signin.xml

Answer 1

Hi @Anonymous ,you can try the following and check if that helps getting you the logo for the MSA IDP:

    <ClaimsProvider>  
      <Domain>live.com</Domain>  
      <DisplayName>Microsoft Account</DisplayName>  
      <TechnicalProfiles>  
        <TechnicalProfile Id="MSA-MicrosoftAccount-OpenIdConnect">  
          <DisplayName>Microsoft Account</DisplayName>  
          <Protocol Name="OpenIdConnect" />  
          <Metadata>  
            <Item Key="ProviderName">https://login.live.com</Item>  
            <Item Key="METADATA">https://login.live.com/.well-known/openid-configuration</Item>  
            <Item Key="response_types">code</Item>  
            <Item Key="response_mode">form_post</Item>  
            <Item Key="scope">openid profile email</Item>  
            <Item Key="HttpBinding">POST</Item>  
            <Item Key="UsePolicyInRedirectUri">false</Item>  
            <Item Key="client_id">{app-id for the MSA App Registration}</Item>  
          </Metadata>  
          <CryptographicKeys>  
            <Key Id="client_secret" StorageReferenceId="B2C_1A_MSASecret" />  
          </CryptographicKeys>  
          <OutputClaims>  
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid" />  
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />  
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />  
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />  
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />  
            <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />  
            <OutputClaim ClaimTypeReferenceId="email" />  
          </OutputClaims>  
          <OutputClaimsTransformations>  
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />  
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />  
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />  
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />  
          </OutputClaimsTransformations>  
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />  
        </TechnicalProfile>  
      </TechnicalProfiles>  
  </ClaimsProvider>  

For the second query, the reason we see a difference here as for the recognition in the Azure Portal is based on the Issuer claim, its used to generate the AltSecId and when we use user flow its a well known name. You can set it to anything in custom policy, which means we cant detect it anymore

If this answer helped you, please mark it as "Verified" so other users may reference it.

Thank you,
James

Answer 2

Im sorry James but I don't understand well your response.

For the first question, you wrote the same XML block that I have in my trustframeworkextensions.xml file (I have checked it, except client_id and StorageReferenceId)

For the second one, If I don't misunderstand you, there is not solution, right? If don't could you please explain it better?

Many thanks for your time :)