Impersonation : Access_token and id_token

I want to use impersonation to log into an angular application from the auth0 dashboard.

I am using the same scope as used during the login : “openid email profile”

The redirect url is good but the id_token parameters seams to be missing.

http://localhost:4200/callback#access_token=GIJitbZSurRH0z8&expires_in=7200&scope=openid%20email%20profile&token_type=Bearer

After reading the documentation it seams that the “openid” scope should be enough for the id_token to appear:

Impersonating a user using the Dashboard will not return a ID Token to your application by default. To achieve this, call the impersonation endpoint manually or in the Advanced Settings. If you call the endpoint manually, add additionalParameters.scope: “openid” to the request body.

In the other hand the access_token is an opaque token:

scope: ‘openid’: (default) It will return, not only an opaque Access Token, but also an ID Token which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim).

My application needs a JWT id_token and a JWT access_token to work.

Is there a way to retrieve a JWT access_token with the opaque token ?

What I’m I missing to retrieve the id_token ?

I kind of suppose It will not be possible to do impersonation properly with this version, will the next version allow me to do it?

For the JWT access token, which would be associated with API authorization functionality, to my knowledge, this is not supported in the currently available impersonation feature.

In relation to the ID token, the openidscope and a token response type should be sufficient to cause the return of an ID token in legacy flows. However, if the client application has enabled the OIDC Conformant toggle in the OAuth advanced settings then an ID token will only be returned if you also include id_token as part of the response type. Given that using impersonation through the dashboard only allows to choose between code and token response types you should use the impersonation API endpoint instead and provide the required response type through the additionalParameters, something like:

"additionalParameters": {
    "response_type": "token id_token",
    // ...
}

Hi @jmangelo, is supporting API authorization with impersonation in Auth0’s development roadmap? This feature is essential when debugging issues only a few users encounter. Also if for some reason the user cannot login through OAuth, there’s now no way for us to get an access token JWT for the user.

Yes, an update to the impersonation API is something on the roadmap and based in the information I have should include support for API authorization access tokens.

This helped a lot, thanks so much

@jmangelo - Can you speak to a timeline on API Authorization with impersonation yet? This is also a key item we’re missing.

1 Like

Nothing concrete on timelines; this is something that I know is on the radar, but there is no definitive dates that I’m aware of. It was not included in the recent roadmap notification so I don’t believe you’ll even have any new about it in Q1.

I was told when asking to turn on the current version of Impersonation for my tenant, that the new version was due out at the beginning of the year. (This was a reply from a ticket opened in October)

I’m just now checking for status on where things are at, and seeing that we wont even “have any new about it in Q1”?

Can you please verify this with Product Management, @jmangelo? I really need to get a definitive quarter where I can plan on this being released… ideally I will integrate when API Auth Impersonation is also available, but could make use of the current ability to “log-in as User” into our app, in the near-term.

Thanks!
John

2 Likes