- Lock v11
- auth0-js v 9.1
I have a React app that is at app.domain.io. My (static, Jeykll) website is at www.domain.io, and is where people log into the app. The general flow is that a login occurs on www, posts to Auth0, which then hits my login callback at app.domain.io/login/callback. That endpoint then runs auth0.parseHash() to grab the access_token from the hash and store it in localStorage, etc.
I just starting trying to use Lock to do this authentication flow from www. The ideal scenario there is that a user click “Log in” on that subdomain, lock pops up, they enter credentials, and it redirects them to app, as a logged in user.
Currently, this works fine in Chrome (OSX), however does not work in Safari and other browers.
As I understand it, this is due to third-party cookies, and some browers not handling them.
Accordingly, I set up the Cross-Origin Verification page at app.domain.io/cross-origin-fallback, which runs the code detailed here: Cross-Origin Authentication
I’m unsure why this isn’t working, however, I do have a question to start with.
As outlined above, the standard authentication flow that I have ends up landing on app.domain.io/login/callback, which does the job of parsing the hash and storing the access_token.
Now, with this fallback URL, that page is never called, which means the access_token is never parsed, the user never authed, etc.
The question is - in this scenario, on which subdomain does the cross-origin verification page live, www or app? Secondly, how do I handle getting the authentication flow to get to that login callback, so I can appropriately parse the token and store it?