We switched to auth0-js 9 from auth0-lock (10, then 11) a few weeks ago, and things were working swimmingly until Thursday morning, when some of our team members were suddenly unable to login or signup. We have the cross origin verification page setup, it works well, and we are even logging customers out before logging in or signing up, but still the intermittent error persists as follows:
What exactly does this error message mean? Can anyone help me discern where it comes from? I see the generic “third party cookies” and “browser not supported” responses, but this is an intermittent error that we’ve seen in chrome and safari, on various machines, that seems to usually go away when Auth0 cookies are cleared, and does not go away consistently when the Auth0 tenant logout url is visited.
Is there any documentation surrounding this specific error? Any response from Auth0 regarding the few of us who are seeing it with no consistent repro or explanation?
My PM received one generic response from Auth0 stating “Thanks for reaching out. Please look at our documentation on Cross-Origin Authentication…”, and nothing past that. Any thoughts from anyone? Anyone? …Bueller?
We were able to connect with support, and it indeed seems like this is a CORS problem due to the auth0 upgrade. We’re about to switch to a custom domain, which appears to solve the problem. The documentation indicates that it’s still in beta, but it appears that with most flows it’s production ready.
Setting up the custom domain was trivial for us, and not having to deal with the CORS issues and having our own auth subdomain are definitely wins. It does appear to be developer (read: paid) accounts only, so if that’s your case, you may need to opt for the universal/hosted login.
We already had a custom domain set up before we started experiencing this problem recently. We are on the latest version of the lock widget and to the best of my knowledge we haven’t upgraded it recently so I doubt it is causing the problems. We are stuck.
The invalid login ticket error some have been experiencing, there was a fix deployed recently and should now be resolved. Please do not hesitate to respond if you notice any unexpected behaviour.
We have a custom login page and in the callback we got error=access_denied&error_description=Unknown%20or%20invalid%20login%20ticket.&state=b4qZRypT7isR5UwbidIixoG~mpKzI1-g
okay, no problem! Thanks for taking the time to respond. Sorry for all the questions, but just a few more! Are you using Lock or Auth0.js? Which version? Lastly, depending on the case, have you implemented the the Cross-Origin Verification Page ?
the error access_denied&error_description=Unknown%20or%20invalid%20login%20ticket is most likely due to blocking of 3rd party cookies in the browser (in chrome for example this is usually reproducible by going to chrome://settings/content/cookies and enable Block third-party cookies) if you are using embedded login (collect the user credentials and use a cross domain authentication) I would suggest looking into implementing theCross-Origin Verification Page as this has resolved the issue in some cases. Other solutions would include moving to Universal Login or implementing custom domains this way the cookies are no longer third-party and are not blocked by browsers.
Yes custom domains can now be used in production tenants.
Also, just to include the information for those curious about the current features that we support with custom domains: Custom Domains and the configuration steps are here: Custom Domains
Kim, we have applied the custom domain solution and now some users are reporting another error:
“Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc”
The only thing we changed code wise was the auth0 domain to the custom domain.
I’m not able to reproduce the issue myself. The users get this in IE and Chrome (at least).
Gotcha! But when you try logging in it works for you? Just not for some users? Our version of auth0.js looks to be okay, version 9 or higher. Can you check if CORS is allowed in Allowed Origins and Allowed Web Origins?
Yes, for me and other users it works but for some it doesn’t work.
In the Allowed Web Origins I had my https://www.{mydomain}.com and in Allowed Origins (CORS) https://*.{mydomain}.com. I added https://www.{mydomain}.com.