Auth0 Home Blog Docs

Working SPA randomly fails to get a valid accessToken

I have a working SPA + API server (thanks to Steve’s QuickStart). The majority of times I receive a full length accessToken and idToken. The accessToken works with my API server. But I am seeing random failures to get a full JWT access_token. I end up receiving a short token that cannot be used by my API server.

  1. Start SPA, login using auth0.WebAuth.authorize(…)
  2. I receive a short accessToken and a full length idToken.

I check my Auth0 logs https://manage.auth0.com/dashboard/us/dev-xxxxx-yy/logs and I do not see any problems. All logins are reported as success.

I am keeping a list of datetime and authResults that contain short access tokens.

If I logout and login with the same user account I usually get a full length accessToken and idToken.

Any ideas as to what is going wrong?

Cheers,
David

At this time, receiving a short access token means that the request did NOT specify a custom API as the audience and as such the service is likely considering this an OpenID Connect authentication request where the access token is only meant to call the /userinfo endpoint.

Given the endpoint above is also controlled by the same service as the issuer of the tokens (Auth0 in this case) then the access token format can just be an opaque token that maps to some data stored on the service side.

When the request includes an audience parameter or a default audience is configured in the tenant settings the service will take in consideration the value of that parameter. If the value is an identifier associated to an API you registered yourself in the dashboard then the issued access token will be a JWT because that’s the only access token format currently supported for the scenario where the entity that validates the access token is not the service itself (in this case it’s an API that you implemented yourself).

In conclusion, the most simple explanation is that somehow your client application has a flow where the audience parameter is not properly configured. More useful than the date/time and actual short access tokens would be to capture an HTTP trace (using Fiddler or browser dev tools).

From this trace it could be possible to confirm if the response that returned a short access token was indeed caused by a request that failed to include your API audience value.