WebAuth checkSession() returns a token that is NOT an AccessToken

[dapug]

I have a SPA app that calls to an API requiring an access token, all set up and working great.

When I sign in using WebAuth (passwordlessLogin), I get an AccessToken as expected (very long string “eyJ0eXAiO…” - probably 400 chars long, huge. API calls with this JWT token work great.

Then later I call checkSession() to “renew” the token. This method succeeds, no error. I clearly get a response back with both authResult.accessToken and authResult.idToken. HOWEVER, what I get this time is NOT an access token! It is a short token (like maybe 30-50 chars), not JWT and cannot be used for calls to the API.

Why? What is this non-JWT token being returned as an accessToken property of the response?

Nothing in the docs explains this.

[john.gateley]

Make sure you are specifying an audience for checkSession.

John

[dapug]

Thank you. Yes, I am using the exact same config (and instance for that matter) for both the initial call, and then the checkSession() call. As mentioned, sign-in (passwordlessLogin) works great, accessToken I get is a valid JWT. But then on checkSession, the accessToken is NOT a JWT, same exact params in WebAuth here!

    auth0 = new auth0.WebAuth({
        domain: AUTH_CONFIG.auth0domain,
        clientID: AUTH_CONFIG.auth0clientId,
        redirectUri: AUTH_CONFIG.auth0CallbackUrl,
        responseType: 'token id_token',
        audience: 'http://localhost:50032',
        scope: 'openid profile read:api'
    })

I just don’t see what I’m doing wrong. Serious head scratcher, and app show stopper.

[dapug]

@john.gateley should I open a support ticket? I’m really not seeing how this is an error on my part, and at the very least, it might be good to be aware that docs are severely lacking if there are multiple token types returned on .accessToken (not just JWT).

[nicolas_sabena]

Hi @dapug.

Can you share a .HAR file that shows the checkSession request via DM? That might help explain what’s going on here.

As for the token formats, Auth0 will issue opaque access tokens when they target an internal Auth0 endpoint (like the OIDC /userinfo endpoint), and JWT tokens when the audience is a custom API (and that’s why the .HAR file will help to check if the audience is being provided in the token request).
I’ll see that the access token formats are made clear in the documentation.