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.

1 Like

I’ve been struggling with this exact problem for a couple days. I think I finally understand based on your response, but let me try to clarify my steps.

I’m using the Auth0 javascript sample #2 (Calling an API). This example makes use of auth0.getTokenSilently() when performing an API call.

Where I have been struggling is that the token returned is a short-opaque token and not a JWT. From your description above, it sounds like the piece I’ve been missing is that I also need to create an API in the Auth0 portal and change the getTokenSilently() line to:

const token = await auth0.getTokenSilently({"audience":"Unique API Identifier From Auth0 Portal"});

However, now I get the following error when making a call to https://mydomain.auth0.com/authorize:

{error: "consent_required", error_description: "Consent required", state: "..."}

And I’m not sure where to go from here. I did discover the blog post OAuth2 Implicit Grant and SPA which has a lot of good background info. As well as Authorization Code Flow with Proof Key for Code Exchange (PKCE) and this code snippet auth0 / spa-pkce. Do I need to modify the getTokenSilently() function to follow this code? Something still isn’t adding up…