Implementing MFA multi-step authentication

[BartKrol]

Hey 👋

We have a requirement for MFA in our project and I'm trying to think what would be a recommended approach for this flow with remix-auth.

The mfa flow has two stages:

1. Login using email and password
2. If successful ask for a second factor code from your mobile phone (this can only happen in a 3min window)

Right now my solution is to authenticate user using the form strategy and then make a decision based on that:

type User =
  | {
      state: "AUTHENTICATED";
      id: string;
    }
  | {
      state: "MFA";
      token: string;
      params: Record<string, string>;
    };

// Use this for Login page
authenticator.use(
  new FormStrategy(async ({ form }) => {
     
     const response = signInWithExternalAuthService(form);
     
      return {
          state: "MFA",
          params: response.ChallengeParameters,
          token: response.Session,
        };
  },
  "username-password"
);

// Use this for MFA page
authenticator.use(
  new FormStrategy(async ({ form, context }) => {     
     const response = respondToMfaWithExternalService(form, context.token);
     
      return {
          state: "AUTHENTICATED",
          params: response.userId,
        };
  },
  "mfa"
);

I feel like this approach is a bit clunky - is there a better alternative to do it :)?

Thanks

[sergiodxa]

I would probably create a custom strategy and store in session some data after the first step, then take the user to the next step UI and once the user sent the second factor token/code/whatever complete the auth storing calling the verify callback where you get the user data.

[webbushka]

@gotgenes This is exactly what I'm looking for, use with cognito. Did you figure out a path forward would love to hear how you're completing this.

[gotgenes]

@webbushka I have done more research and found one project that seems to have multi-step authentication, remix-auth-totp by @dev-xo:

If you look at the authenticate method in the strategy, it seems to accomplish multi-step authentication by

1. storing intermediate state in session (i.e., the user's email) so it can restore this known good state on the next call to authenticate,
2. letting authenticate throw redirects to exit the method and drive the user closer to an authenticated state,
3. declaring the different state transitions using successRedirect in the callers of authenticate (in the route loaders and actions)
4. reading session data in authenticate to identify the appropriate state in the state machine and using the appropriate logic for that state to determine if the user can progress closer to finally being (fully) authenticated.

In effect, this makes calls to authenticate re-entrant.

The aspect that doesn't "fit" to me is that this makes successRedirect in calls to authenticate not actually about successfully completing authentication, but about completing the current stage of auth. Authentication state is split and spread between the Strategy and the caller: the caller to authenticate must be aware where in the authentication state machine they expect the user to be as well as where to send the user in the event the challenge succeeds or fails (the next states in the state machine). This allows the developer to get the two pieces of state out-of-sync: the state machine as understood by authenticate, and the state transitions as defined in the route loaders/actions.

But this is also the path I feel remix-auth pushes developers towards. It's binary: the user either is fully authenticated, or they go somewhere else (like an OAuth IdP, or an internal form with username and password) and come back with all the info, ready to try again.

[dev-xo]

Any suggestions for remix-auth-totp or PRs are welcome @gotgenes, in case you think the Strategy could be improved somehow or opened to more paths (for example, handling the multi-step strategy only, or anything else).

Also, good comment!

[gotgenes]

@dev-xo I don't have an answer yet on how the design could be improved. I'm new to this problem space.

Also, thanks for publishing remix-auth-totp. You provided a clear example of how to achieve multi-step auth with remix-auth. I had a difficult time imagining how this would work, and you provided the "Ah! I see," moment. Thank you!

[dev-xo]

My pleasure @gotgenes, although remix-auth-totp was inspired by a similar auth package (forgot the name, it was kind of outdated as far as I remember).

Also, huge thanks to @mw10013, who improved it and managed it to be in the current state.

---

As I said before, any suggestions or recommendations on how we could improve what we have even more, would be welcome!