We’re having the same issue as above with Safari Users.
Also, we’re getting a weird error when trying to use a verified Custom Domain. '“You should not be hitting this endpoint. Make sure to use the code snippets shown in the tutorial or contact support@auth0.com for help”.
Versions prior to Lock 11 utilize endpoints that will no longer work after April 1:
/ssodata
/usernamepassword/login
If you’re using embedded Lock, upgrading to version 11 is necessary. Lock 11 uses different flows that essentially require custom domains in order for authentication to work across all browsers.
Lock v11 is required is using embedded login (i.e. login on your application as opposed to login in Auth0’s hosted login page).
Cross-Origin Authentication is the new method Lock v11 uses when doing embedded login. If using the hosted login page, Lock v11 should work as before, no custom domain needed.
Custom domains is required to avoid third-party cookies issues when doing Cross-Origin authentication. Thus, if using embedded login, custom domain becomes almost a necessity.
The fallback verification page for cross-origin authentication solves a small subset of issues when it’s not possible to use custom domains. But since it’s not bulletproof, we recommend either using custom domains or moving to universal login (hosted login page).
The fallback verification page shouldn’t be needed if using universal login (hosted login page). There might be a problem in one of the involved components if this is not working in iOS Safari. I’ll have the team check.
We just tried Lock v11 on a hosted login page with iOS and everything works as expected.
If you are using Auth0.js in the hosted login page, take a look at the default template and see if that works fine.
If you are using Lock v11 or Auth0.js v9 in an embedded scenario, Safari will most likely prevent third-party cookies, meaning that embedded login won’t work unless you use a custom domain that matches the domain of your application. I.e. if your app is app.acme.com, your Auth0 custom domain should be something like id.acme.com.
Yes, turns out my user had third-party cookies disabled. In my opinion, this renders Lock 11 pretty much useless for free account users. I will try to get the hosted login page flow to work for my app.
As @nicolas_sabena mentioned, you’ll either need to use the hosted flow or setup custom domains, when using custom domains the cookie is treated as first party.
Yes, turns out my user had third-party cookies disabled. In my opinion, this renders Lock 11 pretty much useless for free account users.
Not trying to sound smarty pants, and I understand your point, but just to clarify: it is the new (and far more secure) embedded login protocol (cross-origin authentication) that requires cross-domain cookies to establish an SSO session in the authorization server. Some browsers block third-party cookies (maybe more will do so in the future), and users can explicitly turn them off. So the only way for embedded login to work is to use the same domain in the app and in the authorization server (Auth0), hence custom domains.
I appreciate the clarification. Quick question about custom domains:
I currently have apps in my account running on two separate root domains. (e.g., myapp.com and someotherapp.com). If I upgrade to a developer pro account is it possible for me to use custom domains for my login for both of these apps? Or no, since we are restricted to one root domain per tenant?
Since I can’t change the app’s domains at this point, I assume hosted login is the only way to go for me right now. Can you confirm? Thanks!
Lock 11 in our Ember.js works for all browsers except Safari with 2 failed silent logins followed by 1 “Unable to configurre verification page” error in the Auth0 logs
I set a custom domain and re-configured our app, then on showing Lock I get "You should not be hitting this endpoint. Make sure to use the code snippets shown in the tutorial or contact support@auth0.com for help” without being able to login (no browser works).
So, with approaching of the deadline next week, the fallback scenario for us is to lock out all of our Safari users, while moving to Lock 11 and not using custom domains.
Not so good. @andre.junior Have you found a solution for the “You should not be hitting this…”?
As this modifications are required to make it work, I wish the API design for configuring Lock on this scenario was easier… adding an ‘overrides’ seems weird.
I thought I’d chime in and express my disappointment in Auth0 here. You’re forcing users into the unknown (into the void) telling them “Just go for it” and when the few survivors come back injured you tell them “Well, whatever, didn’t you purchase our hazard suits? We’re not sure if they’re needed but you can try them as well”. That’s very unprofessional and clearly your team can’t handle it. You still have failed to admit in this thread that Lock doesn’t work without the paid “custom domains” feature (and is useless) and that your documenation is wrong deceiving people and luring them into a trap. Your level of user support is mediocre without anyone caring about this issue which is long-standing and resulting in direct income loss (mac-powered customers) for everyone except you.
Hey’all, I’m having the same problem. I’ve tried everything from @bortevik’s recommendation to @andre.junior suggestion of using overrides. It definitely is a problem for us. Any other suggestion/recommendation would be helpful.
Running into this issue as well. I firmly believe the documentation should explicitly state that embedded login and custom domains only works if the user is coming from the same domain.