-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot impersonate (sign in as) #683
Comments
I have the same problem. The only solution I've found so far is to use It is still unclear on how to do impersonation in a new version. I have a suspicion they are going to deprecate this feature. |
Found it @jimmyn v9.2.3...v9.3.1#diff-2f11667c8f671044416e38e4ceb9d7c8R186 You could argue this breaks semver, but you could argue they fixed a bug |
Hi folks! We're aware of the issue and working in a solution. Thanks for the patience 🎉 |
We're adding a new option so you can enable impersonation again: #689 |
The bug fix breaks semver: https://auth0.com/docs/support/how-auth0-versions-software |
Yes. We're sorry about that. But we're closing an attack vector which is way more important. There will be docs about the trade-offs of using |
hey @Pyrolistical, do you want to test the new version with the flag so we make sure this works in your scenario? I already tested locally, but it'd be good to have an extra pair of hands working on this one! If you want to test it, here's the build file from this PR: https://770-13125982-gh.circle-artifacts.com/0/home/ubuntu/auth0.js/build/auth0.js you'll need to add the webAuth.parseHash({__enableImpersonation: true}, function(err, authResult){
}); |
@luisrudge You are fixing this with an
this allows impersonation to just work. the RS256 signature ensures only auth0 can ever set a valid |
This is a great idea but, unfortunately, a product decision that I cannot make. You can ask reach out to our support team in https://support.auth0.com and add your suggestion there. I'll personally send this to the appropriate team and we'll see how it goes 🎉 |
@luisrudge @Pyrolistical On my end, what I've done is to call checkSession when
Would this then nullify the CSRF attack vector associated with |
checkSession returns the current session in the authorization server (auth0). If impersonation sets a session in the server, then it works. |
@luisrudge Yes it works on my end and so it seems that impersonation does indeed set a session in the server. Thus moving forward, shouldn't that be the default method to use for impersonation rather than setting the |
I'm not sure we want to recommend people calling checkSession if the parseHash fails. I'll talk with the team internally and see what they think. Thanks for pinging me with this info! |
@luisrudge One point to note that is that in the checkSession() method that I pointed out above, the |
@johnlim After reviewing your specific workaround which uses checkSession when the hash fails to be parsed, both our product and security teams are advising against it because this behavior will certainly change in the future. Moving forward, we want developers to think about the implications of enabling the |
@luisrudge Thanks! Will Auth0 provide more information on the implications and how we can mitigate them in the near future? At the moment, when I read the documentation, it seems to be flashing a big red flag that says "Use at your own risk!". |
This is in our docs: https://auth0.com/docs/user-profile/user-impersonation#enable-impersonation, it's not a flashing warning, but a warning anyway 😝 |
when "sign in as" is used from user management, it triggers the application configured callback:
http://localhost:9000/auth0-callback#access_token=some-access-token&id_token=some-id-token&scope=openid&expires_in=86400&token_type=Bearer
notice, there is no state.
but in auth0.js v9 we have:
auth0.js/src/web-auth/index.js
Lines 180 to 191 in 2ca7ccf
it always trips "state does not match"
The text was updated successfully, but these errors were encountered: