Well, you're talking about a multi-steps authentication process where there is an intermediate page (or dialog) that is dynamically loaded, depending on the username and the 2FA implementation that is currently effective for that username (user). For instance: username == xxxx ---> SQL query (2FA enabled for xxxx?) < - yes/no -> Yes ? --> which 2FA implementation for xxxx ? <- Yubikey OTP -> load Yubikey OTP intermediate form, then, ask the user to fill the field for YubiKey OTP authentication and finally, on form submission, process the authentication. That is what you want meant?
This could be done this way of course. I'll review this in a later YubiKeyAuth plugin version, and when the google 2fa auth plugin will be ready.
BTW:
By doing this way, some crazy people could even add many 2FA implementations in the authentication process ---> step1 credentials, step2 Yubikey OTP, step3 Google Authenticator .... Our authentication class is based on events where an authentication handler is an event listener that listen on the onAuthenticate event.
There can be many authentication handlers listening on the onAuthenticate event, and each of them can short-circuit the event at any time, meaning that any other handler would be discarded, or which can lets other handlers do their job. In that later case, there are many steps required in the authentication process, each listener implementing it own authentication logic. Here, the authentication process would succeed only if all handlers would return a success authentication result. This is already what I do with the YubiKeyAuth plugin which provides its own handler (listener tha listen on the onAuthenticate event that is triggered by i-MSCP). However, depending on the administrator setup, that handler, which is registered with high priority, lets the default credential authentication handler do its job or not (think of single-factor auth using Yubikey only).
