Impersonation API: response_type: 'token' not working

Help
, , , ,
1

Hi,
I had a working implementation of impersonation, and it seems that today it stopped working because the impersonation API MY_DOMAIN.auth0.com/users/USER_ID/impersonate is generating an impersonation url with a redirect that no longer contains the id_token and access_token in the hash of the callback url. I have not made any code changes related to my API call since it was last working.

For the call to the impersonation API endpoint, if I change the additionalParameters.response_type to ‘code’ instead of ‘token’, a code will be appended to my callback url as a query string parameter, but my SPA at the callback url would really like the tokens as it had before.

My question is: has support for response_type: ‘token’ been dropped or otherwise broken recently? And if it is still a functional feature, what might I be missing that’s necessary for it to work?

Here’s a sample request payload:

{"protocol": "oauth2","impersonator_id": "MY_IMPERSONATOR_ID","client_id": "MY_CLIENT_ID","additionalParameters":{"response_type": "token","state": "", "scope": "openid profile", "callback_url": "https://localhost:8080/logout"}}

(I also have a valid bearer token in the request Authorization header)

2

In this question:
http://community.auth0.com/questions/4726/does-anyone-else-use-impersonation-and-has-securit
, a user reports that technical support has provided him with the following information:

“Note, that we do not recommend using
the impersonation feature as it may
introduce security vulnerabilities
into your application. We are working
on a new impersonation implementation,
however don’t yet have an ETA for
this.”

I’d also love a clarification from someone at Auth0 about these vulnerabilities, and if there’s a way for me to protect against them from my end. I’m tasked with creating an impersonation tool for my team, and this will affect whether the whole initiative is viable.