Over the past few months we’ve had to make a couple requests to enable impersonation in the different environments that we use for testing and QA. In one of the responses, we were informed that impersonation is being overhauled to address standards compliance and some other security concerns. At the same time, we have seen certain endpoints being deprecated for Lock and self hosted Auth0 solutions while those same endpoints are still supported in Universal login (I’m looking at you /ssodata endpoint!).
In an effort to build our authenticationo solution for longevity we have disabled all of the legacy APIs and moved to the new Auth0.js libraries. This has led to soem inconsitancy in how SSO is handled :
- For normal login sessions, we are able to use the /user/ssodata endpoint in the hosted login page to detect whether or not the user is signed in. If they are, we call webAuth.authorize() and the user is silently authenticated
- For Impersonation sessions, we must handle this on the client side by passing “prompt=none” and attempting silent authentication. We aren’t able to use the new checkSession() call in the hosted login page since it triggers some CORS validation, and we aren’t able to detect whether an SSO session is impersonated or not from the hosted login with /ssodata.
Since the two calls cannot be handled the same we are effectively handling silent auth entirely on the client side, which means that each application that uses Auth0 needs to have this logic included.
Ideally, SSO requests could be handled entirely from the hosted login page, but this just isn’t possible right now. I tried using webAuth.authorize() in the hosted login page for impersonated sessions as well, but that call fails.
Basically, I’m wondering if these inconsitancies will be resolved in an upcomming release? If so, do you have an idea of when that might happen (6 months, year, more)?