Integrate the Mozilla China phone number verification screens behind a feature flag

[shane-tomlinson]

The Mozilla China stack has phone number verification screens, we should add, behind a feature flag, so that team can stop worrying about doing it every time we update the content server.

This feature is only enabled for OAuth reliers.

┆Issue is synchronized with this Jira Task
┆Issue Number: FXA-730

[shane-tomlinson]

cc @l-hedgehog

[l-hedgehog]

Hi, just to clarify, since we're currently using a fork of mozilla-services/msisdn-gateway but the instance at https://msisdn.services.mozilla.com/ is long gone, when preparing my PR, I should propose any necessary changes directly in fxa-auth-server instead of assuming that service could be revived, right?

[davismtl]

I recommend we look into re-prioritizing this and even enabling it for a lot of markets.

I see this having many benefits:

• could help reduce spammy accounts since phone numbers are harder to burn through (think AMO problems with spammy webextension submissions)
• could help for login if the primary email is lost (we could send a link / code by SMS instead)
• could be an option for 2FA, instead of email and TOTP
• combined with other data, it could lead to a path forward for TOTP recovery (though alone, it's not secure enough to recover TOTP)

[shane-tomlinson]

TL;DR - Yes, we need to expand SMS capabilities, however, @l-hedgehog implemented a phone number verification system that is tailored to Mozilla China's needs, including where verifying control of a phone number takes place in the flow. I would be extremely hesitant to use it for the rest of the world in its current form.

As Hector points out above, their logic is is based using the no-longer maintained mozilla-services/msisdn-gateway to send SMS and verify control of a particular phone number.

There are some things that stand out about this approach:

1. The msisdn-gateway hasn't been updated in 4 years.
2. The msisdn-gateway has a totally different use case than our needs, in FxA terms, it is the auth server, it authenticates users by sending SMS's. Since it's an authentication system, it has to return a proof of identity. The proof it uses is a BrowserID assertion, which we are actively trying to remove all traces of. Because msisdn-gateway is a full authentication system, it involves a lot of complexity we just don't need.
3. We already know how to send SMS. We send lots of them.
   • While we've talked about extracting an SMS sending service from the auth-server, msisdn-gateway is not the generic SMS sending service we hoped for.
4. It has been a long while since looking at the code, but I remember seeing some client side logic I wished were on the server.

[davismtl]

@shane-tomlinson
Am I understanding correctly that I should file a separate bug since the China integration doesn't seem ideal for the use cases I described?

[shane-tomlinson]

@shane-tomlinson
Am I understanding correctly that I should file a separate bug since the China integration doesn't seem ideal for the use cases I described?

Ya.