Jetpack SSO bypasses local 2FA (regression in 0.15.0)

[kraftbj]

Describe the bug

Prior to 0.15.0, Jetpack SSO and Two Factor worked together without conflict. Users who authenticated via WordPress.com SSO (which has its own 2FA) were not prompted for local Two Factor verification. This worked through two mechanisms:

1. filter_authenticate_block_cookies (added in Block sending authentication cookies upon 2FA login #502 by dd32) only suppressed auth cookies when did_action( 'login_init' ) was true — the inline comment explicitly noted this was "to ensure we're within the regular login flow, rather than through an unsupported 3rd-party login process." SSO authenticates outside wp-login.php, so login_init hadn't fired.

2. The wp_login action (which triggers the 2FA prompt via show_two_factor_login()) fired globally, but Jetpack SSO authenticates users and sets cookies through its own path without calling wp_signon(), so this hook never fired in that context.

PR #660 refactored this by consolidating the two authenticate filters into one and replacing the did_action('login_init') guard with a strlen($username) check — SSO doesn't pass a username through the authenticate filter, so the effect was the same. The wp_login hook was also moved to conditional registration inside filter_authenticate, so it only fired for username/password logins.

Then #793 reversed the key parts of #660: removed the $username parameter and strlen($username) guard, moved both the authenticate filter and wp_login hook back to unconditional registration in add_hooks(), and removed the argument count from the filter registration. The net result is that filter_authenticate now fires for any WP_User with 2FA enabled regardless of how they authenticated, and the wp_login hook fires unconditionally at PHP_INT_MAX.

For SSO users, this means the 2FA flow is triggered even though they've already completed authentication (including 2FA) on WordPress.com. I see the WP_Error data rendered as a raw object at the top of the page followed by a local 2FA prompt.

These two plugins have worked side-by-side for years, and I'd guess other plugins that authenticate users outside the username/password flow (OAuth, SAML, etc.) are probably affected the same way.

For reference, there's some prior history here: #84 and #122.

Steps to Reproduce

1. Install and activate Jetpack (with SSO enabled) and Two Factor.
2. Configure a user with a Two Factor method (e.g., TOTP) and connect their account to WordPress.com via Jetpack.
3. Log out.
4. Click "Log in with WordPress.com" on the login screen.
5. Complete WordPress.com authentication (including WP.com's own 2FA if enabled).
6. On redirect back, instead of being logged in, you see a raw object dump and/or the local Two Factor prompt.

Screenshots, screen recording, code snippet

The guard in #502 (2023, survived until 0.15.0):

public static function filter_authenticate_block_cookies( $user ) {
    /*
     * NOTE: The `login_init` action is checked for here to ensure we're within the regular login flow,
     * rather than through an unsupported 3rd-party login process which this plugin doesn't support.
     */
    if ( $user instanceof WP_User && self::is_user_using_two_factor( $user->ID ) && did_action( 'login_init' ) ) {
        add_filter( 'send_auth_cookies', '__return_false', PHP_INT_MAX );
    }
    return $user;
}

The #660 replacement (also worked):

public static function filter_authenticate( $user, $username, $password ) {
    if ( strlen( $username ) && $user instanceof WP_User && self::is_user_using_two_factor( $user->ID ) ) {

Current code after #793 (no guard):

public static function filter_authenticate( $user ) {
    if ( $user instanceof WP_User && self::is_user_using_two_factor( $user->ID ) ) {

I don't know what the right fix looks like from Two Factor's side — restoring strlen($username) might re-introduce whatever #793 was solving. A filter (something like two_factor_user_requires_authentication) that external auth plugins could hook to signal "2FA was already handled" might be a more durable solution, but that's just one idea. Open to whatever makes sense for the project.

Environment information

• WordPress trunk (6.8-alpha)
• Two Factor 0.15.0
• Jetpack (trunk)

[dd32]

In some respects, It was expected that SSO bypassed 2FA, but on the other, it's also expected that 2FA should apply to the user no matter the authentication source. IMHO.

[nimesh-xecurify]

I think we should be prompting for 2FA regardless of the auth source. Even if it's a change from previous behavior, a generic 2FA plugin shouldn't be bypassed just because someone uses SSO. Consistency here is better for security.

[kraftbj]

I think there should be a way for these different things to work together. SSO with Jetpack, Google, etc could offer their own 2fa (Jetpack has an option to force only allowing SSO if the WP.com account has 2fa enabled).

[dd32]

Part of the problem is that SSO often doesn't tell the site how someone has authenticated: User+Password? Existing Session? 2FA? Passkey? etc.

It's 100% possible for SSO to bypass Two-Factor entirely, even with this change, it's just that due to the order and hooks in use, Jetpack SSO is not bypassing the 2FA checks. Automattic/jetpack#47306 is a good example of that, but if Jetpack SSO was via admin-post.php or a custom PHP handler and not wp_login filters, it'd have also bypassed. This is how many of the Hosting panel auto-login's work.

Something to note, is that if SSO was to bypass 2FA, the users session won't be flagged as being 2FA'd which may have implications in the future. At present, it only causes attempting to change 2FA settings to prompt for 2FA. In the future, or on specific sites, this might limit access to certain capabilities (ie. no super admin until 2FA'd, or no admin-level settings, etc)

two-factor/class-two-factor-core.php

Line 1389 in c8fcc8c

public static function is_current_user_session_two_factor() {

[kraftbj]

I think there can be a way to play nicely together here. SSO providers providing the information the 2fa plugin wants and 2fa plugin providing site owners ways to control it.

For example, my use case is WP.com SSO and native login as an option. I can force 2fa for WP.con SSO. I want users to go through some form of 2fa, but I don't want an experience of login to WP.com (or Gmail or GitHub or whatever else), provide a authenticator code or security key, then have to provide another authenticator code. If someone logins natively, then I do want a 2fa process via this plugin to gate them.

I've heard of others who want a 2fa code requested because they see a passkey only login as not 2fa (I understand that and assuming the security of the passkey device is high is a fallacy).

So to me, how can we create a smooth experience for users and provide site owners the ability to set the security level to match their risk profile?

[kasparsd]

Considering that:

1. the previous behavior was to disable 2FA when WP-com SSO is used,
2. and we have a dedicated compat file;

could we update this here to preserve that old behavior? What would be the best patch here?

two-factor/class-two-factor-compat.php

Lines 43 to 62 in c8fcc8c

	public function jetpack_rememberme( $rememberme ) {
	$action = filter_input( INPUT_GET, 'action', FILTER_CALLBACK, array( 'options' => 'sanitize_key' ) );
	if ( 'jetpack-sso' === $action && $this->jetpack_is_sso_active() ) {
	return true;
	}
	return $rememberme;
	}
	/**
	* Helper to detect the presence of the active SSO module.
	*
	* @since 0.5.0
	*
	* @return boolean
	*/
	public function jetpack_is_sso_active() {
	return ( class_exists( 'Jetpack' ) && method_exists( 'Jetpack', 'is_module_active' ) && Jetpack::is_module_active( 'sso' ) );
	}

[masteradhoc]

@kraftbj @dd32 we're planning to release version 0.16.0 soon. Any feedback to the comment of @kasparsd here?
Then we can try to draft a PR here to get it released in 0.16. A PR from your side ofc would also be helpful.

CC: @georgestephanis