Access token not recognized on subsequent calls to the API

[sean.feldman]

I’m running into an issue with a single user where, after a successful login, the user shortly after gets an error Microsoft.AspNetCore.Components.WebAssembly.Authentication.AccessTokenNotAvailableException. This is a Blazor WebAssembly application. Looking at the Auth0 logs, the user’s subsequent requests are failing with the Login required reason in the logged Failed Silent Auth entries. The user is experiencing the same problem using Chrome, Brave, and Edge. All up-to-date. It’s specific to a single computer.

I’ve taken steps to guide the user to wipe the cookies and cache. That didn’t help the problem. I’ve captured a HAR file confirming what I’ve described.

Any other device is working fine. What could be causing this?

[dan.woda]

Hi @sean.feldman,

I understand you are having trouble maintaining a login session for a particular user, on a single machine.

You can DM me the HAR file and I’ll take a look. Additionally, can you please provide the tenant’s name and user ID?

[sean.feldman]

DM with the information sent. Thank you, Dan.

[sean.feldman]

I’ve looked into the tenant configuration, and something doesn’t add up.
The tenant is configured to use cookies

But when I inspect the cookies, there’s no Auth0 cookie - only Azure-related ones.

But under session storage, I do see the following:

Shouldn’t the cookie be generated based on the Auth0 settings in the portal? The Blazor WebAssembly app has the following configuration:

builder.Services.AddOidcAuthentication(options =>
{
    builder.Configuration.Bind("Auth0", options.ProviderOptions);
    options.ProviderOptions.ResponseType = "code";
    options.UserOptions.RoleClaim = ClaimTypes.Role;
}).AddAccountClaimsPrincipalFactory<AccountClaimsPrincipalFactoryEx>();

This follows the recommendations on securing Blazor WebAssebly applications by Auth0.

[sean.feldman]

I’ve sorted out what the problem was. It was a misconfiguration. To summarize it, Auth0 has a tenant settings with sessions configuration (Tenant → Settings → Advanced → Login Session Management). There an inactivity timeout can be defined for users. In a SPA, that’s not everything as there are backend API endpoints the app is talking to. And those, can have a different configuration for access token duration (Applications → APIs → → Settings → Token Settings → Token expiration.
In my case, those didn’t match and while the user session was still good to go, calls to the API endpoint were failing as the access token was expiring.

I’m no expert in security, hence using Auth0
Whish Auth0 had the smarts to point out that a user session and an API endpoint access token had different values, which could be the desired state but could lead to unexpected behavior, which is what happened to me. Hope this helps someone down the road. Or refreshes my memory the next time

[dan.woda]

Thanks for posting a detailed update @sean.feldman!