Invalid state after login

[helloIAmPau]

Hello all. I’m trying to implement the authentication flow for my spa but I always receive an “invalid state” error on my callback page.

My application lives at “https://app.local.io” and my callback service lives at “https://auth.local.io”.

here is how I configured my spa application:

this is the authentication part of my app

    const getAuth = function() {
      if(_auth !== null) {
        return Promise.resolve(_auth);
      }

      return createAuth0Client({
        audience: config.audience,
        domain: config.domain,
        client_id: config.client_id
      }).then(function(auth) {
        _auth = auth;

        return auth;
      })
    };

      return getAuth().then(function(auth) {
        return Promise.all([ auth.isAuthenticated(), auth ]);
      }).then(function([ isAuthenticated, auth ]) {
        if(isAuthenticated === true) {
          return;
        }

        return auth.loginWithRedirect({
          redirect_uri: config.redirect_uri
        });
      });

and this is the relevant part of my callback page:

    createAuth0Client({
        audience: config.audience,
        domain: config.domain,
        client_id: config.client_id
      }).then(function(auth0) {
        return auth0.handleRedirectCallback();
      }).then(function() {
        var destination = window.location.origin.replace('auth', 'app');
        window.location.repalce(destination);
      });

it looks like it doesn’t set the auth0_state cookie.

Is there something I’m missing in the configuration?

Thanks

[jmangelo]

To my knowledge the SDK will set a cookie specific to the full domain where the SDK is being used, however, you’re using one domain to start the login and a different one to process the callback so it’s likely that the cookie is being set, but on app.local.io and as such unavailable once the response is returned to auth.local.io.

Can you expand on the use case for starting the login in one domain, but handling it in another one? Given they share a parent domain you can likely workaround this with custom logic, but that would seem unnecessary overhead.