Auth0 Universal Login window auto-closes after ~3 seconds during first registration — no user record created

We run a passwordless authentication system using Auth0 via the openid-connect-generic plugin on WordPress. New users register via MemberPress, which creates their WordPress account and session before they reach the Auth0 step. We have identified a specific failure point in the registration flow where Auth0 closes automatically without user interaction, preventing the Auth0 record from being created. The full sequence and our hypothesis are detailed below.

Stack: WordPress, MemberPress, BuddyBoss, Auth0, openid-connect-generic (daggerhart), Cloudflare Turnstile, Rapyd hosting, LiteSpeed server.

Confirmed registration sequence:

  1. New user completes MemberPress registration form

  2. Cloudflare Turnstile validates successfully

  3. MemberPress creates WordPress user, assigns membership, and auto-logs user in natively

  4. WP Fusion fires — assigns BuddyBoss profile type, group, MailerLite sync

  5. User redirected to /start

  6. Auth0 Universal Login window appears via openid-connect-generic (Auto Login - SSO mode)

  7. FAILURE POINT: Auth0 window closes after ~3 seconds without user interaction — no Auth0 record created

  8. User lands in correct BuddyBoss group newsfeed via native WP session from step 3

What should happen at step 7: Auth0 should remain open and prompt the user for their email to receive a passwordless one-time code, completing the handshake and creating their Auth0 record.

Root cause hypothesis: MemberPress creates a native WP session at step 3 before Auth0 fires. Auto Login - SSO mode appears to detect this existing session and auto-close without prompting the user.

Question: Is Auto Login - SSO designed to skip authentication when an existing WordPress session is detected? If so, how do we force the full passwordless handshake on first registration regardless of existing WP session state?

Once the mebership is created, auth0 login works seamlessly, it is only on new member signup.

Hi @craig8

Welcome to the Auth0 Community!

As you have stated, the core issue might be an identity state caused by allowing MemberPress to natively create the WordPress user and establish a local WordPress authentication session (Step 3). You are effectively bypassing Auth0 as the Identity Provider (IdP).

The daggerhart OpenID Connect plugin (acting as the Service Provider) detects this active local WordPress session and abruptly aborts the Auth0 SSO flow, which is why the window closes and the Auth0 user record is never provisioned.

To ensure the full passwordless handshake occurs and the Auth0 record is created, you must enforce Auth0 as the sole session issuer. You have to intercept the MemberPress flow before it creates that native session by preventing it from automatically logging the user into WordPress after checkout. If I am not mistaken, MemberPress provides a hook to disable this behavior. You can add this snippet to your child theme’s functions.php or a custom plugin:

add_filter('mepr-auto-login', '__return_false');

Once auto-login is disabled, the user will complete checkout but will remain unauthenticated in WordPress. You must then configure MemberPress’s post-registration redirect to immediately forward the user to the daggerhart plugin’s dedicated login route, which triggers the Auth0 Universal Login.

To make the UX seamless, since the user just typed their email into MemberPress, you can append it to the authorization request as a login_hint . This pre-fills the Auth0 Passwordless screen so the user only has to click “Send Code”:

Let me know if the proposal above fixes the issue that you are experiencing or if you have any other questions!

Kind Regards,
Nik

1 Like

Thank you so much for this — what a relief to read!

You’ve diagnosed it perfectly, and I’m happy to confirm that the mepr-auto-login filter is already in place in our child theme’s functions.php, exactly as you’ve described. The moment we implemented it, the issue resolved completely.

It’s really reassuring to have the technical explanation explained by you (I’m neither a coder nor developer!!) — understanding why it works matters as much as the fix itself. The login_hint improvement is also noted and on our list for a future refinement.

Thank you again for taking the time to provide such a thorough and clear response. Genuinely appreciated.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.