2FA auth flow does not utilize refresh tokens

[slifty]

It looks like #175 did not account for the processTwoFactorCodeResponse flow, which means if a user has 2FA enabled then they get an auth token with no refresh token.

We'll need to refactor to have both flows set up refresh tokens properly. This work may be done as part of #288, but I wanted to open the issue separately since they are technically separate issues.

[slifty]

Looked into it more -- it appears that the final step of 2FA does not have a 202 response (that's the one that would signal the user isn't a client. I think we're going to need to make sure the user is registered for the application BEFORE begining 2FA flow (but after password).

This would mean a flow like the following:

1. Attempt to login
2. If the account has 2FA, then take the extra step of attempting to retrieve the user and confirm they are registered with the sftp application. If they are NOT, we would register before invoking the 2FA flow.
3. invoke the 2FA flow.

One "downside" to this is that someone who knows the user's password could trigger that registration with the SFTP service. Now, I don't think that causes any actual harm (and indeed we were thinking about just automatically registering all users with SFTP as a potentially desired approach), but I wanted to raise it.

---

An alternative would be to simply reject any user with 2FA enabled, and avoid any complications at all. Given that the most likely long term solution to SFTP authentication is to avoid passwords and 2FA entirely / rely on SSH keys... that might not be a bad plan?

[slifty]

WAIT! I found the proper documentation: https://fusionauth.io/docs/apis/login#complete-multi-factor-authentication

And I do see a 202 response there 🎉

The question now is whether we can re-use the same MFA key to submit a second login request (e.g. "log in with MFA, get a 202, register the user, log in again with the same MFA).