expose id_token

I want access to the raw id_token (from the /oauth/token response). My “serverless” single-page app integrates with a third-party app that needs an oidc token, access tokens are not appropriate. I found that id_token is digested into the User object (accessible from useAuth0) but then that token is cached & inaccessible. The auth0-spa-js and auth0-react SDKs (nevermind the Auth0 dashboard & docs) don’t address this problem.

Blog articles why-should-use-accesstokens-to-secure-an-api come somewhat close, but again do not recognize that the 3rd-party Service will have the same relationship to Auth0 as Auth0 has to (e.g.) Google OAUTH. Based on an id_token, Service will establish a user and issue its own access/refresh tokens.

Describe the ideal solution

useAuth0() should provide a method to get the authenticated user’s id_token, or maybe the id_token should be a static member of the user object. (The latter might be easier and require modification in auth0-spa-js only, but I see reasons to not make that object a Christmas tree.)

Alternatives and current work-arounds

There is more than one strategy to intercept fetch/request/xhr responses, but these are not accessible to a moderately skilled frontend dev. SAML et al are not available or preferable for my intended 3rd-party Service (MongoDB Realm, btw).

Additional context

I look forward to discussion here, I’ll likely submit a PR here and/or on auth0-spa-js sometime.

[stevehobbsdev]

If that’s the supported way

@khitrenovich This is the supported way and you should continue to use __raw if you really need the raw ID token. We would not remove it without considering it a breaking change. We will also take on board the feedback to improve our docs in this area, but we’re not sure yet what form that will take.

[khitrenovich]

We had similar need, and ended up using __raw property too. If that’s the supported way, having it officially documented would be nice. If not, then we do need something supported.