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?
#8

Hello,

I’m having a potentially similar issue using Lock via AngularJS 1.x without a custom domain

I’m running Lock 11.5.1 and instantiating via the lockProvider called like this:

lockProvider.init({
clientID: redacted,
domain: redacted,

        options: {
            allowedConnections: ['google-oauth2',
                                 'Username-Password-Authentication']
                                 ],
            _enableIdPInitiatedLogin: true,
            allowShowPassword: true,
            allowSignUp: false,
            autoclose: true,
            languageDictionary: {
                title: 'Slideboxx'
            },
            auth: {
                responseType: 'token id_token',
                audience: 'https://' + 'redacted' + '/userinfo',
                params: {
                    scope: 'openid profile email'
                }
            }
        }

Any hints on what I need to change to get impersonation working.

Thank you

#9

I think you have an extra ] in allowedConnections :slight_smile:

I also found that I need to specify the scope when I impersonate (to be the same scope passed in params at init).

#10

Thanks Sally, the extra ] was an edit error when I removed some of the actual code :slight_smile:

Where are you specifying the scope when you impersonate?

thanks again!

#11

In the dialog that opens when you click the “Sign in as user” button -> “Show Advanced Settings”.

#12

Thanks again Sally.

For what it’s worth, impersonation was apparently failing because the angularjs (1.x) library angular-lock.js was not passing the _enableIdPInitiatedLogin flag to webAuth.parseHash

I added this flag to my local copy of angular-lock.js and impersonation works, the diff is

35a36,38

    var allowIdPInitiatedLogin = false;
    if (this.options._enableIdPInitiatedLogin === true)
      allowIdPInitiatedLogin = true;

95c98,99
< { hash: hash, _idTokenVerification: shouldVerifyIdToken },

            { hash: hash, _idTokenVerification: shouldVerifyIdToken,
              __enableIdPInitiatedLogin: allowIdPInitiatedLogin  },
#13

Hey Sally. This was posted several months ago but I wanted to post this for anyone who was a bit confused about the overrides in their lock configuration.

overrides: {
   __tenant: config.auth0Tenant, // Refers to that user's TENANT
   __token_issuer: config.auth0Domain // Refers to that user\'s CUSTOM DOMAIN
}

If anyone would like to troubleshoot the config values, you can simply use a console.log(config) from the hosted login page, then attempt to log in and look at the developer console. Probably not the cleanest solution, but it gives you an idea of what the config values are. To my knowledge, Auth0 doesn’t document these values terribly well (but maybe I simply haven’t found that documentation).

#14

Thanks a lot @royce for sharing your solution with the rest of community!