Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passwordless login fails for first login on macOS/iOS Safari #820

Closed
alexbaulch opened this issue Aug 20, 2018 · 9 comments

Comments

@alexbaulch
Copy link

@alexbaulch alexbaulch commented Aug 20, 2018

  • Auth0.js version => 9.7.3
  • Browser & OS => Safari - macOS 10.13.4/iOS 11.4.1

Hey guys,

I have a React/Redux SPA set up with a custom passwordless login form the utilises auth0.js to handle the generation of the login code. At the moment though every time a user tries to login for the first time in Safari (on either iOS or macOS) they get an error saying Unable to configure verification page..

After a decent amount of hunting through closed issues on here, I came across this which seemed to suggest I needed to use a custom domain in order to get it working. Having now implemented the custom domain I am still getting the same issue so am wondering what, if anything, I need to do to get around this issue?

Having read through the issue linked above quite extensively I thought I would add that I also get an issue when using https://brucke.club, albeit a different one to the issue I am experiencing. The logs for a first time login are below:

{
 "event": "a0js_parse_hash",
 "arguments": [
  {
   "error": "invalid_request",
   "errorDescription": "No verifier returned from client.",
   "state": "cvTSJ78N1uqn1a65VfOfUM.A.okUri~5"
  },
  null
 ]
}
@luisrudge

This comment has been minimized.

Copy link
Contributor

@luisrudge luisrudge commented Aug 21, 2018

Hi! This is all because of the ITP (Intelligent Tracking Prevention) system that Apple released. You can read more about this here:

Safari 11:
https://webkit.org/blog/7675/intelligent-tracking-prevention/
https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/

Safari 12:
https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

We and other Identity Providers are in direct talk with Apple about this but, for the current time, there's nothing we can offer you that would make this work 100%, except using the Universal Login Page.

Another workaround for the time being is catching this error and just trying to re-authenticate the user. The experience is not great, but it might work, since the cookies are sent in the second request.

@luisrudge luisrudge closed this Aug 21, 2018
@chrisyaxley

This comment has been minimized.

Copy link

@chrisyaxley chrisyaxley commented Aug 21, 2018

That really is a terrible user experience.

@luisrudge

This comment has been minimized.

Copy link
Contributor

@luisrudge luisrudge commented Aug 21, 2018

It absolutely is. That's why we're leading a group of Identity Providers in this talk with Apple. I'm running the beta version of macOS (Mohave) and running Safari 12 in my machine (Safari 12 uses ITP 2.0) and I can login in the first time but, then again, ITP actually works by keeping track of your previous accessed URLs, so it might not work for other users.

Another workaround worth trying is catching this error and calling webAuth.checkSession (from Auth0.js). Considering this makes another request using an iframe, it might as well send the cookies and you can get your tokens back.

The conversation with Apple is ongoing and I'm hopeful we'll have more to share in the next weeks.

@marcusletric

This comment has been minimized.

Copy link

@marcusletric marcusletric commented Sep 24, 2018

I have the same issue using LoginAndRedirect method from Auth0-js. Whenever I open a private window then try to log in, the first time redirect happens after authentication the callback URL has error: Unable to configure verification page.

Subsequent logins working fine...

Chrome, FF, IE11 and EDGE does not suffer from this.
Any updates on a fix for this?

@richardblocksure

This comment has been minimized.

Copy link

@richardblocksure richardblocksure commented Nov 1, 2018

Why is this closed ? The fact that @luisrudge and auth0 are in conversations with Apple does not make this issue as resolved - it just makes it "in progress". We are on the verge of releasing a new update to our software where we decided to risk going "all-in" with authentication via Auth0, and this behaviour is suboptimal to say the least.

The last update from @luisrudge was on 21st August finishing with "more to share in the next few weeks" - can we have an update on this please? Does it look like a fix is forthcoming and in what timescale ?

@thoean

This comment has been minimized.

Copy link
Contributor

@thoean thoean commented Nov 1, 2018

It's not helping resolving this problem, but we worked around this limitation in our library auth0-sso-login.js. We're avoiding the call to checkSession on the first login, but instead parse the hash. We're still using checkSession for follow-up checks to keep the user logged in on long website sessions. The related pull request was PR 36 in auth0-sso-login.js.

Again, not a solution to this problem, but hopefully some inspiration on how some applications can work around it.

@luisrudge

This comment has been minimized.

Copy link
Contributor

@luisrudge luisrudge commented Nov 1, 2018

Conversations on this topic are still ongoing. A few days ago, we were advised by Apple to build our case in the public tracker for the Storage Access API Proposal. We started publicly doing that 3 days ago. All future discussions will be made in that thread.

It's important to remember that the Storage Access API thread has nothing to do with ITP itself. Using the new API would be a way to mitigate the effects of ITP.

For now, the only workaround is to use custom domains.

@richardblocksure this issue is closed because this is not a bug, it's limitation that is documented here: https://auth0.com/docs/cross-origin-authentication#limitations-of-cross-origin-authentication

@richardblocksure

This comment has been minimized.

Copy link

@richardblocksure richardblocksure commented Nov 1, 2018

Thanks @luisrudge . I will follow and comment (where appropriate ) on the thread you have highlighted. I understand this is frustrating for all parties involved and appreciate your efforts in mitigating the effects. My concern is that other browsers soon follow suit and make the resultant experience unpleasant.

@luisrudge

This comment has been minimized.

Copy link
Contributor

@luisrudge luisrudge commented Nov 1, 2018

@richardblocksure Firefox is implementing the Storage Access API as well. The problem isn't so much with the new API, is how the browser blocks the 3rd party cookies. Firefox, for example, has a list of known trackers and will block them, so Auth0 won't be affected. Apple, on the other hand, is using its own process (ITP) to flag a domain as tracker and it might flag Auth0's domain in some cases.

The good thing is that if you have one app running at https://myapp.com, you can use custom domains do make Auth0 available at https://auth.myapp.com and then this will never be an issue.

Thanks for the patience and understanding while we try to come up with something better 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.