Catering for testing and automating when you use phone login with OTP with Azure AD B2C

This is based on this sample.

Note: there are other phone samples in the samples pack.

This sample shows how to sign up and sign in with a phone.

When you SUSI, you select the country from a drop-down list of country codes and then enter the phone number. An OTP is then sent to the phone that you have to enter to confirm that you own the phone.

This is fine in normal use but I have come across two problems in certain scenarios:

• The county codes in the custom policy are restricted e.g. to the APAC region and the lab. that certifies the application is in the USA and doesn’t have access to a phone / SIM from that region
• For automated testing, there is no way to enter the OTP

One way around this is to bypass the SMS code for a specific phone.

Here, you would use the original policy to sign up with a phone. That ensures that the phone number is in the B2C tenant.

Assume the phone number was +6128123456.

Then the new code would be:

<Actions>
 <Action Id="SendCode">
  <ValidationClaimsExchange>
   <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="CombineCountryCodeAndNationalNumber"/>
   <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AzureMfa-SendSms">
    <Preconditions>
     <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>signInNames.phoneNumber</Value>
      <Value>+6128123456</Value>
      <Action>SkipThisValidationTechnicalProfile</Action>
     </Precondition>
    </Preconditions>
   </ValidationClaimsExchangeTechnicalProfile>
  </ValidationClaimsExchange>
</Action>
 <Action Id="VerifyCode">
  <ValidationClaimsExchange>
   <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="CombineCountryCodeAndNationalNumber"/>
   <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AzureMfa-VerifySms">
    <Preconditions>
     <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>signInNames.phoneNumber</Value>
      <Value>+6128123456</Value>
      <Action>SkipThisValidationTechnicalProfile</Action>
     </Precondition>
    </Preconditions>
   </ValidationClaimsExchangeTechnicalProfile>
  </ValidationClaimsExchange>
</Action>
</Actions>

So if the phone number matches, then skip the “AzureMfa-SendSms” and “AzureMfa-VerifySms” steps.

The user enters the phone number. In the background, the SMS is not sent. You still see the screen to enter the OTP but you can enter any number since it’s not verified.

For a ValidationTechnicalProfile you would have, e.g.

<ValidationTechnicalProfile ReferenceId="AzureMfa-SendSms">
 <Preconditions>
  <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
   <Value>signInNames.phoneNumber</Value>
   <Value>+6128123456</Value>
   <Action>SkipThisValidationTechnicalProfile</Action>
  </Precondition>
 </Preconditions>
</ValidationTechnicalProfile>

You add this code around all the “AzureMfa-SendSms” and “AzureMfa-VerifySms” steps.

There is a security risk here in that someone could “discover” the phone number but remember that the phone has to be registered in the tenant. You can’t just make up a number.

And remember that it is only for this one custom policy.

The key is what the attacker could do if they did get in. In this use case for a customer, not a lot. The advantages of having automated testing etc. was judged to be worth it.

The other way is to assign an extension attribute to the test users.

The code would then check the presence of that attribute:

<ValidationTechnicalProfile ReferenceId="AzureMfa-SendSms">
 <Preconditions>
  <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
   <Value>extension_skipOTP</Value>   
   <Action>SkipThisValidationTechnicalProfile</Action>
  </Precondition>
 </Preconditions>
</ValidationTechnicalProfile>

However, here you would have to read Azure AD to get the attribute.

So you would to invoke:

“AAD-UserDiscoveryUsingLogonPhoneNumber-FullProfile”

or

“AAD-UserDiscoveryUsingLogonPhoneNumber-Common”

and add the extension attribute as an output claim.

I haven’t tried this but it should work.

All good!