Add support for the MFA workflow

[typerandom]

How to verify

In order to activate the MFA workflow, you need to configure the mfa policy resource of your application as shown below:

POST /v1/mfaPolicies/(YOUR MFA POLICY ID)

{
  "status": "ENABLED",
  "mode": "account-configured",
  "allowedTypes": [
    "sms",
    "google-authenticator"
  ]
}

Fixes #56

[nbarbettini]

Awesome work @typerandom! 🔥

Kicking the tires a little bit:

• I sent myself a code, re-sent a new code, then entered the first one. The UI said that my device was added successfully but the factor was not verified.
• Once I have an unverified phone on my account, I'm stuck and can't verify it or remove it.
• The Security Code field should automatically get focus after the code is sent or re-sent.
• I think that manually entering the TOTP key should be hidden behind a link. It's a little intimidating to see a long ass key. A "Can't scan? Click to enter manually" link might be better UX.
• When logging in, if you accidentally click Google Authenticator when you meant to click SMS (or vice versa), it's not possible to get back to the "Verification Required" starting point. You have to cancel the whole thing and type in your email/password again.

[nbarbettini]

One other thought: The Device Added success screen doesn't have a clear call to action. To newbies it may be non-obvious that you have to click away to close.

The Forgot Password flow also has this issue, which I bugged in #144

[nbarbettini]

Another other thought: I think this message could be simplified.

End-users don't care about Factors or Accounts. "This phone number has already been added to your account" is cleaner IMO.

[robertjd]

Thanks @nbarbettini for the detailed review! We still need to add Client API endpoints to handle the "you already have an unverified factor of that type/phone number" story.

[typerandom]

Just want to give an update here! Thanks @nbarbettini for all the feedback! That was really awesome! I've been working today on fixing these things and I have completed most of them.

[typerandom]

My update here so far.

I sent myself a code, re-sent a new code, then entered the first one. The UI said that my device was added successfully but the factor was not verified.

This bug has been fixed.

Once I have an unverified phone on my account, I'm stuck and can't verify it or remove it.

Yes, this is currently a limitation in the API. We’d need to have support for GET /factors in or to be able to detect any existing unverified factors to be able to rechallenge them.

The Security Code field should automatically get focus after the code is sent or re-sent.

This has been fixed.

I think that manually entering the TOTP key should be hidden behind a link. It's a little intimidating to see a long ass key. A "Can't scan? Click to enter manually" link might be better UX.

This has been fixed.

The Device Added success screen doesn't have a clear call to action. To newbies it may be non-obvious that you have to click away to close.

The window now autocloses after 5 seconds with the text “Device added - You’ll soon be redirected to your application.”

Another other thought: I think the message “An existing phone with that number is already associated with a factor for that account” could be simplified.

This has been fixed.

When logging in, if you accidentally click Google Authenticator when you meant to click SMS (or vice versa), it's not possible to get back to the "Verification Required" starting point. You have to cancel the whole thing and type in your email/password again.

This is still being worked on. But expect to have this a little bit later today.

[nbarbettini]

Great progress @typerandom! 💯

[robertjd]

Thanks @typerandom ! Here is my review, some of which we have already discussed on slack:

• [x] The enrollment success view could use some love, it should read "your factor has been setup successfully", and it should not auto-close. The user should close the modal after they have grokked the message.

• [ ] I have to press the enter button twice to submit the phone number form when I am enrolling with SMS. The first press has no affect.

• [x] If my access token has expired, but I try to create a factor, the API errors and the MFA view just sits there. A check might be useful here, otherwise let's just assume the developer has already handled the logout state and the user can't access the MFA workflow?

• [x] When creating a GA factor, we need to set a unique 4-character string for the issuer field, so that the user can disambiguate between our GA entry and other entries that they may already exist in the app for their email address. This is a workaround until we modify the MFA Policy to allow the developer to specify the issuer for the application. We already did this for ID Site, please use this function to create a nice alphanumeric string. Then it will look like this for the end-user in their GA app:

• [x] Following the last point, the factor select view also needs some love. Here are the points, and a screenshot that shows how I think this could look:

  • The language should indicate your factors, to indicate that these are factors that the user created (right now it feels like you're being asked to setup new ones).
  • We should show the hints that are provided by the factor_select response at this step, to further re-enforce that these are factors that the user already has.
  • 

[typerandom]

Regarding:

I have to press the enter button twice to submit the phone number form when I am enrolling with SMS. The first press has no affect.

This seems to be related to autocomplete. I'm looking into how to fix it. Could you just verify that it only occurs when you select something from autocomplete and not when you enter it manually?

[typerandom]

Also, thanks for the feedback! It was really good and I agree with all of the changes.