Blazor WASM oidc auth is trying to authenticate using expired refresh token

[wim07101993]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have an application which authenticates to a keycloak instance using openId connect. After a while the acces-token an refresh token are expired (on my environment the expiry-time is rather small to do some tests).

.Net however does not seem to notice this and requests a new access-token using the expired refresh-token. This ofcourse results in a 400 response from keycloak ({"error":"invalid_grant","error_description":"Token is not active"})

Expected Behavior

When the refresh-token is expired: The user should be redirected to keycloak, in this case, to reauthenticate.

Steps To Reproduce

My configuration:

        var configSection = configuration.GetSection("Authentication:Schemes:Oidc");

        services
            .AddOptions<OidcOptions>()
            .Bind(configSection)
            .ValidateDataAnnotations()
            .ValidateOnStart();

        var oidcOptions = configSection.Get<OidcOptions>();

        services
            .AddAuthorizationCore(options =>
            {
                // add policies
            })
            .AddCascadingAuthenticationState()
            .AddOidcAuthentication(options =>
            {
                options.ProviderOptions.Authority = oidcOptions.Authority;
                options.ProviderOptions.ClientId = oidcOptions.ClientId;
                options.ProviderOptions.ResponseType = "code";
            });

Exceptions (if any)

No response

.NET Version

.net8

Anything else?

No response

[MackinnonBuck]

Thanks for reaching out.

This behavior is by-design. You can catch the AccessTokenNotAvailableException and handle the scenario explicitly, as shown in our docs: https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/additional-scenarios?view=aspnetcore-9.0#attach-tokens-to-outgoing-requests:~:text=%22WebAPI%22))%3B-,The%20configured%20HttpClient%20is%20used%20to%20make%20authorized%20requests%20using%20the%20try%2Dcatch%20pattern,-%3A

Please let us know if this helps your scenario!

[wim07101993]

Even if the behavior of throwing an exception is expected, why would the application need to try to send the request to the idp? Wouldn't it be better to just throw the exception then?

(The solution provided by @MackinnonBuck did solve the user-problem)

[MackinnonBuck]

@wim07101993, the client doesn't necessarily know when the refresh token expires; the server can revoke the refresh token at any time.

[wim07101993]

True but if the client already knows that the token has been expired, it does not need to make the network request. Does it?

[halter73]

I'm not sure the client has a way to know if the refresh token is expired other than trying it. The normal expires_in property on the OIDC /token response is for the access_token not the refresh_token. A quick search indicates that some OIDC servers provide a refresh_expires_in value, but it's nonstandard. And I don't think the refresh token is required to be a JWT, so I don't think we can read an exp claim.

[MackinnonBuck]

We're going to close this as answered. Please open a new issue if you still believe there's a product change we should make here.