Hi,
I am facing a weird issue with Auth0 sign in for google users. I have implemented SPA loginwithPopup method in my application due to client requirements, instead of universal login. If the user has enables 2-step verification in google, and the user tries to sign in the first time, the user gets stuck on a URL that looks like this https://{Auth0 domain}/resume?state={state value}
This doesn’t happen all the time though. Sometimes the login popup automatically closes and goes back to my application, but there are times it doesn’t. Instead just shows a blank white popup stuck on that URL, after users accepts 2 step verification via their mobile requested by google. Reading Auth0’s documentation all I have found is the “continue” state URL. Nothing mentions about “resume” in the URL.
I need help as my clients are frustrated as to why these edge cases keep happening in between as they want a 100% working authentication flow.
I have the exact same issue you describe but have not been able to find a solution and it is a nightmare to test since I can’t reproduce the issue in a lot of browsers and it happens to just a few users on specific browsers, we think it is cookie related but no luck so far. Have you been able to pinpoint the cause of the issue?
Same issue here. We have a custom universal login & MFA pages, if it’s any relevant.
So far, I’ve only heard reports of the issue happening on Safari mobile (iOS).
I think the solution is to ditch loginWithPopup and use loginWithRedirect instead, unfortunately.
My theory atm is that this may be due to privacy restrictions imposed by the browser which might interfere with the auth flow, but I can’t say for sure.
This issue has been reported many times in the past, but there hasn’t been a resolution to the underlying problem [1][2][3][4]
With us. It was working fine until few days ago we started to get this issue. Even though we bumped the latest version, the issue persists. Anything that Auth0 support suggest here?
The culprit on our app was the “helmet”. We bumped the version from 4.x.x to 7.x.x and I guess there are some default CSP that are stricter. We pinned down the helmet to 4.x.x and it is working as usual. Will post if we find out what in v7 broke it.