Azure B2C Login Username or Email with MFA choices

[germanyesid]

I have been working on creating a custom policy to allow users to log in using either their username or email, along with the option to select their preferred MFA method.

As a base, I used the example policy SignUp_SignIn_PhoneOrEmailMFA. While everything works correctly when logging in with an email, I am encountering an issue when logging in with a username. Specifically, the correct email value associated with the user is not retrieved.

Login with Email (The flow works as expected, and the correct email is retrieved)

Login with username (The email is not retrieved correctly)

Could you please assist me in resolving this issue? I would like to ensure that the correct email is retrieved regardless of whether the user logs in with their username, email or another method.

[TheUniquePaulSmith]

Ironically, I just built something like this to support username or e-mail based sign-in with MFA.
What we did was store the e-mail in a custom attribute that was dedicated for e-mails and reference that attribute in the MFA technical profile that used it for OTP.

We also built several claimstranformation rules to determine whether an e-mail or username was used to login
Here's a snippet of user journey after authentication

   <!-- Read AADObject user data if email -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>isEmail</Value>
              <Value>True</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="LookupOnEmailSignIn"
              TechnicalProfileReferenceId="AAD-Lookup-By-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Read AADObject user data if username -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>isEmail</Value>
              <Value>True</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="LookupOnUsernameSignIn"
              TechnicalProfileReferenceId="AAD-Lookup-By-Username" />
          </ClaimsExchanges>
        </OrchestrationStep>

[dlRo]

Got it! Spent a good part of this weekend figuring this out. Nowhere could I find a complete answer so: here it is. The sample you've linked to is great when users' logon with an email address but some users of our B2C logon with username instead. The EmailVerifyOnSignIn technical profile is doing all the work and leverages the ReadOnlyEmail claim which of course is read-only and pulls from the logon id and if it's a user name that ain't gonna work. My first ah ha moment was simple swap out ReadOnlyEmail for something editable (ultimately that became an extension attribute) but what happened was every iteration became editable. I wanted just the first iteration to be editable and subsequent calls would pull that saved extension attribute value read-only. Here we go:

• Create an extension attribute to save and replay the email address users will enter when prompted, per your screen shots. I called mine extension_mfaEmail.
• You will need 3 journey steps. The third one is the exact one from the sample, just add a precondition that checks to see if extension_mfaEmail exists (If ClaimsExist is False, skip).
• The first of the 3 is a copy of the 3rd, but flip the extension_mfaEmail precondition (if exists, skip - we want this one to run if it doesn't exist so we can capture it and save it). The technical profile it calls is a copy of EmailVerifyOnSignIn, let's call it EmailVerifyOnSignInPrompt. The changes to that one are: change the input and output claim from ReadOnlyEmail to extension_mfaEmail (of course).
• Now the one in the middle. This simply pulls extension_mfaEmail from AAD. The technical profile that goes with this one is a lot like AAD-UserReadUsingObjectId (not surpringly) just add Metadata (Operation = Read), a couple PersistedClaims, the Output claim is extension_mfaEmail, IncludeTechnicalProfile use AAD-UserReadUsingObjectId, and create a ClaimsTranformation that transforms extension_mfaEmail to ReadOnlyEmail (!!) and call it.

One more note: users who need to change their email address after it's locked in, or maybe want to change MFA methods from phone to email or the other way (I have authenticator app as a 3rd option) will need to be reset so the choice is made available again. 3 cmdlets:

Reset-EntraStrongAuthenticationMethodByUpn -userprincipalname {user-id}@<your_b2c_domain>.onmicrosoft.com
Invoke-MgGraphRequest -Method PATCH -Uri 'https://graph.microsoft.com/beta/users/{user-id}' -Body @{ extension_<b2c-extensions-app-guid>_mfabyphoneoremail = $null } -ContentType 'application/json'
Invoke-MgGraphRequest -Method PATCH -Uri 'https://graph.microsoft.com/beta/users/{user-id}' -Body @{ extension_<b2c-extensions-app-guid>_mfaEmail = $null } -ContentType 'application/json'

I think that's everything - good luck!

[JasSuri]

You can find the user using signInNames, which searches any matching identifier.

Then when reading the user back, you should read the email back from signInNames.emailAddress, assuming that’s where it’s stored.

You can use extension attribute, but they aren’t uniquely constrained, unlike signInNames collection.