We have a SPA + API flow pretty much exactly as it described here. We used to use id_tokens, but are now using access_tokens to authenticate to our API as is recommended by the docs. We are also setting our clients to be OIDC compliant which is also recommended for future-proofing.
Authentication works fine, but I using the impersonation endpoint, the callback is loaded with an opaque (non-JWT) access token, indicating that it is not designed to be used for custom API authentication, even when the audience value is passed into additionalParams and when a default audience is declared at the tenant level.
Other issues seem to suggest this is a known limitation of the platform as it currently exists. Is this the case? I find it very hard to believe that Auth0 would point its users to specific architecture which specifically excludes one of their valuable features (impersonation). We have done a fair bit of work to update our stack in the way that Auth0 prefers, and to find out at the end of this that we have actually lost a feature that we used to have is pretty disappointing.
The impersonation API does seem to provide valid id_tokens, which we could perhaps use to authenticate to our API, but they lack scopes which our API uses.
Am I missing something? Can anyone at Auth0 recommend a course of action to enable impersonation in a SPA + API scenario? Impersonation is a crucial part of our application that we can’t afford to lose. Thanks