We use auth0-js SDK (v9.10.0) to handle IdP initiated auth for our SPA.
We get a browser hash when the user lands into our app. Here is the current flow:
const auth0 = new WebAuth(...)
if (auth0 hash in url) {
auth0.parseHash({__enableIdPInitiatedLogin: true}, cb1)
} else {
auth0.checkSession({}, cb2)
}
We are running to some issues when thinking about changing this flow, so I would like to understand how this works.
The url hash that I see as an access_token param, but the token isn’t a valid JWT access token. What is that access token?
To get a proper JWT access_token, today we call another checkSession in cb1 to get a valid JWT token.
For some IdP flows, I was able to simply remove calling parseHash and directly call checkSession. It worked for some but not others. Is calling parseHash required? If yes, why?
The access token you receive that is not a JWT is likely an access token only suitable to call very specific API’s in the Auth0 service itself. In particular, it should be usable to call the /userinfo endpoint to get some info about the user, mostly the same information you would be able to already get from validating an ID token.
The use of IdP-initiated flows to translate a SAML IdP-initiated response into an OIDC one is indeed not the general recommendation. Given parseHash is mostly a client-side operation the fact that you call that method or not before a checkSession operation should be irrelevant.
In other words it’s unexpected for checkSession to be influenced in any way by the fact that parseHash was called before so the different outcome may be due to something else. However, it’s hard to guess so the best approach would be for you to try to compare the flows at the network level (HTTP traces) to see if you spot any difference between when it works and when it does not.
Thanks for the response! This helped us clear confusion and we were able to resolve our issue. Our code is now simpler too - we don’t call parseHash anymore!