[SR] Facilitate 2FA+MultiFactor compatibility (2FA/two-factor -> MFA/multi-factor)

(Filing this feature request as a result of a short mention in today's BD weekly meetup.)

Two concerns, but only 1 relevant for core, hopefully with at least a clarification / guideline in place before or on the release of 1.8. Not sure how much needs to be done code-wise for core. If a separate/new API is the answer, then the initial question is if we can do something "imperfect" only partially to help various ports of contrib modules from D7 head "in the right direction" or take a "unified approach".

Most (all?) of the existing/relevant modules may well reside in contrib, but the question is how core can help them avoid race conditions and incompatibilities. Does that constitute an effort too big to consider for inclusion in 1.8.x?

For actual examples, here is my initial list of the most relevant contrib modules:

• https://www.drupal.org/project/tfa
• https://www.drupal.org/project/tfa_basic (TOTP++)
• https://www.drupal.org/project/u2f
• https://www.drupal.org/project/yubikey (the latest Yubikey's also have u2f, but the current YK module does not have that capability)
• https://www.drupal.org/project/login_one_time (authorised roles/admins may send such links from inside the site to users that has problems logging in. The destination path provided in the setup of that module should not come in conflict with other 2FA/MFA requirements for that user/login.)
• https://www.drupal.org/project/login_destination (similar problem as with login_one_time: also should not come in conflict with 2FA/MFA, but be handled at the end of the login process (race condition))
• https://www.drupal.org/project/passwordless (enforces logins using an email link instead of the normal password, but the second (or third++, as in MultiFactor) factor(s) should still apply AFTER that)
• https://www.drupal.org/project/legal ("Terms-of-Service" module that needs reconfirmation/acceptance of new revisions upon login before granting access (if not accepting, may remove related roles, but still allow login (with less features). That process should not prevent 2FA/MFA to kick in when applicable.)

• https://www.drupal.org/project/apply_for_role (buy membership level (roles for Premium.content++))

• Other modules related to Registration (several candidates).

Examples:

Below are some examples on which "issues" we need to fix when porting those modules to BackdropCMS, related to the above modules (based on current situation/experience from D7):

(Notice that these examples are mostly issues that needs to be fixed in each contrib module. THIS feature request related to BD core is simply a question of identifying what/how core can facilitate and help guide these ports into a constructive direction where race conditions and incompatibilities can be avoided from the start.)

• passwordless (email link instead of password) is most often/likely the first part of the login process. It does not redirect properly when (some) other(s) of these modules are active, so that TFA/Yubikey/etc. does not get to work after this module has accepted the login. The result is currently aborted logins.

• TFA_basic (TOTP/Google Authenticator compatible) should allow the login to proceed through other steps as well, such as subsequent Yubikey / U2F.

• ToS updates may aim to PREVENT login if the new ToS revision is not accepted, thus it needs to come FIRST in the login process (second if using "passwordless" / email login links), before the TOTP/Yubikey/U2F kicks in.

• Yubikey module has options for disabling username/password and only use YK for login. When an account also has activated TOTP or email-login (passwordless), those should also get to work without conflicts with YK. This part of the features might be the one we want in core: the very setting per account for how many and which authentication elements are required (also depending on roles; so the combination of roles is key here)

• legal does not get to do its renewal of acceptance on new ToS revisions if some of the above modules also kick in at the same login time.

(PS. The world is about to realize that two-factor is important but not enough by itself, depending on the sensitivity of the content/accounts/site(s) in question. We need to cater for all. If you look at for example Google's password recovery process, that is already multi-factor (and a great example). We need to aim for multi-factor functionality already now, not just two-factor.)