Auth0 Home Blog Docs

Cannot impersonate user after upgrading to lock 11

lock
custom-domain
angularjs
#1

Hi, I’m migrating from lock 9 to 11 in an AngularJs app. We also switched over to using a custom domain. Things are generally working, except that I can no longer use the ‘Impersonate User’ feature from the Dashboard. It appears that two things are going awry:

  • I’m getting the "state does not match" error, even if I set a state value when I initialize lock and use the same value in the impersonation advanced settings. (Oddly, the value that is set in local storage by auth0 is not the value I added in the impersonation advanced settings.)
  • It also appears that the token contains the .auth0.com domain instead of the custom domain, leading to an error, “Issuer https://.auth0.com/ is not valid.”

How can we continue to use impersonation on lock 11 with a custom domain?

#2

We will soon be releasing an updated idpInitiatedLogin flag which will resolve this case in Lock via:

_enableIdPInitiatedLogin: true

What I am getting from Engineering is the following code should resolve this:

var options = {
  overrides: {
    __token_issuer: 'mydomain.auth0.com'
  }
}
#3

Thanks for your response! I tried adding

overrides: {
  __token_issuer: 'mydomain.auth0.com'
}

to the options when I initialize lock. I first got an error because __tenant: 'mytenant' is apparently also required in overrides?

Sadly, I’m now getting a generic WE'RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO LOG IN message in the lock widget.

I tried using the custom domain and the tenant.auth0.com domain as __token_issuer:. Both resulted in the same error. Which is correct?

As a sidenote, I saw documentation of the overrides config in the custom domain documentation but didn’t think it applied because it didn’t appear in the Embedded Lock section. The documentation is a bit confusing in that regard.

Separate question: Do you have a sense of when the idpInitiatedLogin flag will be released?

#4

If you can get the raw error using the error events (https://github.com/auth0/lock#onevent-callback) and report back that would be helpful as it’s hard to track down without it.

We will be releasing the Lock update soon and will let you know when that happens.

#5

I’d love to send you a more helpful error, if only I was getting one! I have listeners in place for both 'authorization_error' and 'unrecoverable_error' that should log the errors in the console, but nothing at all is showing up. When I add debuggers in the listeners, they never get triggered.

#6

A new Lock version has been released which supports the flag mentioned earlier. In understand that this recent issue is more related to the issuer, however, given that you likely update to this can we troubleshoot the full situation in latest version.

Can you update to Lock 11.5.1 provide the full configuration used to instantiate Lock both on login pages and redirect pages (unless the config is exactly the same). In addition, provide an HAR file for the series of requests starting with the impersonation one that then lead to an error (you can redact sensitive information like opaque access tokens or signatures of JWT tokens).

#7

Sure, I can do that. But before I do, I’d like to make sure that I’m configuring the overrides correctly. In the docs for custom domains, the example shows options like:

...
	configurationBaseUrl: config.clientConfigurationBaseUrl,
	overrides: {
		__tenant: config.auth0Tenant,
		__token_issuer: config.auth0Domain
	},
...

but doesn’t specify what config contains.

Two questions:

  • Is the __tenant simply the string of the tenant name, like mytenant if the auth0 (non-custom) domain is mytenant.auth0.com?
  • Is the __token_issuer the custom domain or
    mytenant.auth0.com?