WordPress.com VIP Go MFA incompatibility

[kevinfodness]

Description

WordPress.com VIP Go will be requiring all users that have edit posts capabilities to use their MFA system as of May 29, 2019. If a user on a VIP Go site configures MFA on their account, they can no longer log in using Auth0, as the authentication flow presents a white screen when the MFA prompt should appear.

Although there are filters to disable the requirement for users to use MFA on VIP Go sites, users are still able to configure MFA on their profile, and if a user has MFA active, it will lock them out of their account when attempting to log in using Auth0.

This is a particular problem on multisite networks, in which Auth0 may not be used for login on all sites in the network, and MFA would be configured on the network-level account for non-Auth0 sites. A common use case here would be where the root site in the network is a corporate website where only employees will be logging in using their WordPress credentials with MFA configured, and one of the subsites supports public registration using Auth0 for community engagement.

Prerequisites

• Have you read Auth0's general contribution guidelines?
• Have you read Auth0's code of conduct guidelines
• Did you check the documentation?
• Did you check the Auth0 Community?
• Did you check the WP.org Support Forum?
• Are there any related or duplicate Issues or PRs in this repo?

Environment

Please provide the following:

• WP-Auth0 version: 3.10.0
• WordPress version: 5.2
• PHP version: 7.3
• Browser version, if applicable: Chrome Mac 74.0.3729.131
• Additional active plugins that might be relevant: VIP Go mu-plugins: https://github.com/Automattic/vip-go-mu-plugins

Reproduction

On a site that is using VIP Go mu-plugins (all sites on the WordPress.com VIP Go platform), configure a user account with MFA at the bottom of the user's profile page (/wp-admin/profile.php#two-factor-options), then attempt to sign in using Auth0 in an incognito window.

I used the "sign in with Google" button, and it took me through the authentication process with Google, and when it redirected back to the site it yields a nearly empty page - there is just a link for "back to [site name]". I have MFA configured with WordPress.com VIP Go via email, and I confirmed that the MFA email was sent from my VIP Go site, but the prompt to enter the MFA code is not present, and I am not able to finish the login process to the site.

This error is consistently reproducible.

There are no PHP or Auth0 plugin error log entries.

JSON export of settings: https://gist.github.com/kevinfodness/635e68236d5ffc6bc76da87b50842a91

Screenshot of nearly blank screen after returning from Auth0 login workflow:

[joshcanhelp]

@kevinfodness - Thank you very much for this report and all the details! I'm happy to take a closer look and see what we can do but, in the meantime, have you tried with Features > Universal Login Page turned on?

[kevinfodness]

Hi @joshcanhelp —

Thanks for the suggestion, but unfortunately, the same behavior exists when I turn on that setting.

[joshcanhelp]

@kevinfodness - One more option ... we adjusted how the core WordPress login forms are handled and will be releasing that soon. Are you able to test with the master branch here? I think what's happening is that the form they're using for MFA is being hidden by CSS loaded by the plugin. You can try this out by inspecting that area and looking for a hidden form. It might just be that we need to adjust some CSS to get this working.

If not, or if that does not work, I'll need to try this out on their platform. I'm looking into local development options (edit: found EasyEngine, working well so far) now but is it possible to spin up a test site that I could take a look at? If so, you can send details to me directly at josh dot cunningham at auth0 dot com.

Thank you!

[joshcanhelp]

I was able to get a local setup running and it looks like my theory on what's happening here is correct. That form is hidden by default and the embedded form shows (this is with the master branch here).

You can tinker with the CSS to show the form but submitting it is not accepted (as expected, we're trying to keep out unknown/unauthorized attempts to use the core login form). I think we just need to look for the request that this form is attempting and allow it. I'll take a look at that next week and get it into the next release if it's not a big overhaul.

[kevinfodness]

Sounds great! Looking forward to what you can do here. Thanks so much for the assistance.