Cross-Origin Authentication Across Subdomains

  • 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: https://auth0.com/docs/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?

This is happening me too.

Hey there!

Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.

Wanted to reach out to know if you still require further assistance?