Problem providing Access Token to HttpClient in Interactive Server mode

[RobJDavey]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When making authenticated requests in InteractiveServer mode, a user's access token is required to talk to an external service. As the guidance is that it is not safe to use the IHttpContextAccessor when in server interactive mode, I have been following the documentation to try and add a token provider servicer.

I've followed the documentation guides below, however the access token on the token provider in interactive server mode always comes through as null. I'm unsure if I have misunderstood or missed something in these guides or if the guides do not currently lead to a complete solution.

• Server-side ASP.NET Core Blazor additional security scenarios
  • Pass tokens to a server-side Blazor app
  • Set the authentication scheme
  • Access AuthenticationStateProvider in outgoing request middleware
• ASP.NET Core Blazor dependency injection
  • Access server-side Blazor services from a different DI scope

The sample project I have attached tries two different approaches to get this access token.

The first is the inject the TokenProvider into the WeatherService, and grab the token from it there. This works fine when using server side rendering, but the token is null when in interactive server mode.

The second is to try use a circuit handler to set the correct services for the circuit, allowing it to access the TokenProvider from inside other services by injecting the CircuitServicesAccessor. The circuit handler however never seems to get the CreateInboundActivityHandler, and so I have been unable to test whether the TokenProvider it would provide would contain a null access token or not.

Expected Behavior

When a HttpClient request is made in InteractiveServer mode, the TokenProvider configured in the App component should be passed to the WeatherService class so it can be used to set the Authentication header.
Alternatively, the AuthenticationStateHandler class should get the CircuitServicesAccessor set by the ServicesAccessorCircuitHandler, which can then be used to access the TokenProvider class to get the token.

Steps To Reproduce

I have created a sample solution which shows what I have attempted so far:
https://github.com/RobJDavey/BlazorTokenIssue

The README explains how to run the solution. While there are 3 projects in the solution, 2 of them are purely there to support the demonstration, it's only the BlazorApp service that is at issue.

To authenticate, please user the either username and password alice/alice or bob/bob as these are the test users configured.

The SSR page always loads the data from the external service fine, however the Interactive Server page fails due to the missing token.

Exceptions (if any)

A 401 is returned by the service when no valid access token is attached.

System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
   at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
   at BlazorApp.Services.WeatherForecastService.GetForecastAsync(Int32 skip, Int32 take) in ./BlazorApp/Services/WeatherForecastService.cs:line 34
   at BlazorApp.Components.Pages.WeatherInteractive.<OnInitialized>b__8_0(GridItemsProviderRequest`1 request) in ./BlazorApp/Components/Pages/WeatherInteractive.razor:line 47

.NET Version

8.0.100

Anything else?

cc: @guardrex dotnet/AspNetCore.Docs#31113

[gragra33]

Have you looked at using a DelegatingHandler to manage this? Here is a YouTube video by @m-jovanovic that shows you how: Middleware Pattern For HttpClient With Delegating Handlers.

[RobJDavey]

@gragra33 yes I do have a DelegatingHandler in the project: https://github.com/RobJDavey/BlazorTokenIssue/blob/main/BlazorApp/AuthenticationStateHandler.cs

This does not appear to get given the configured TokenProvider when running in interactive mode though.

Based on this guidance, as this handler could be called from an interactive context, it cannot just grab the token off the HttpContext which is why the TokenProvider approach appears to be necessary.

[gragra33]

@RobJDavey based on your implementation TokenProvider will always have null values.

namespace BlazorApp.Services;

public class TokenProvider
{
    public string? AccessToken { get; set; }
    public string? RefreshToken { get; set; }
}

builder.Services.AddScoped<TokenProvider>();

You should have a TokenProviderFactory class to populate and return a TokenProvider, typically, values are stored in the appsettings.json. This is mentioned, in a more simpler way, in the above YouTube video. Here is the timestamped position in that video: Middleware Pattern For HttpClient With Delegating Handlers @ 3:10

Here is what your implementation should be:

public class TokenProviderFactory
{

    private IServiceProvider _serviceProvider;

    public TokenProviderFactory(IServiceProvider serviceProvider)
        => _serviceProvider = serviceProvider;

    public GenerateTokenProvider<TSettings>() where TSettings : IProviderSettings
    {
        var settings = _serviceProvider.GetRequiredService<IOptions<TSettings>>().Value;
        return new TokenProvider()
            {
                AccessToken  = settings.AccessToken;
                RefreshToken = settings.RefreshToken;
            };
    }
}

remove:

builder.Services.AddScoped<TokenProvider>();

and replace with:

builder.Services.AddScoped<TokenProviderFactory>();

now update:

var tokenProvider = _circuitServicesAccessor.Services?.GetRequiredService<TokenProviderFactory>().GenerateTokenProvider<GitHubSettings>();

*Note: the above code is typed freehand here and not tested but should work as-is. I am sure that there is enough there to help solve your issue.

[RobJDavey]

@gragra33 the token provider is not for client access tokens, but user tokens retrieved at login via OpenIDConnect, so they cannot be stored in settings.

The token provider is configured to have the current user's access token in the App component which is based on this guide.

This works fine in server side scenarios, but not in interactive.

[gragra33]

@RobJDavey I have not run your code, so I did not dig that deeply. Now I have.

However, have you set breakpoints in:

1. WeatherForecastService - when the TokenPrivder is being populated
2. AuthenticationStateHandler - when the TokenPrivder is being used

Is the TokenProvider being set before being used in AuthenticationStateHandler?

I would also add a constructor in the TokenProvider, with a breakpoint, to check when it is being created and if, and when, it is occurring more than once.

[RobJDavey]

@gragra33 the construction of the TokenProvider is occurring twice, which is part of the issue.

The first time is for the server side rendered version of the page which is getting the access token set correctly, and is successfully making the HTTP call to the external service.

The second time is for the interactive client services, which as I understood it is what the circuit services accessor is supposed to help with. Maybe I have misunderstood what this is for. As this is creating a new version of the TokenProvider, rather than using the existing one that was populated in the App component, it provides a null access token and gets a 401 (Unauthorized) back from the external service. As I mentioned in the issue though, I am never seeing the CreateInboundActivityHandler method called so I may be doing something wrong here.

Ideally when the Blazor Hub receives a message I'd be able to just grab the token from the user's HttpContext, but the documentation makes it clear this is not safe to do in an interactive context. This is why I'm trying to follow the guide to get the TokenProvider working.

One approach I have tried which does seem to work is using the IHttpContextAccessor in the CircuitHandler.OnCircuitOpenedAsync to populate the TokenProvider, however I am not sure from the documentation about IHttpContextAccessor whether this is considered safe to do so ideally would like some clarification from someone very familiar with the Blazor hub if this is a safe thing to do or not.

[gragra33]

@RobJDavey I noticed that @mkArtakMSFT tagged your issue with Doc. It made me curious, so I downloaded your solution and ran it.

I set a breakpoint in the OnInitializedAsync method in the App.razor component, OnInitialized method in the WeatherInteractive.razor component, and in the GetForecastAsync method in WeatherForecastService. I then navigated to the page. and observe the order of breakpoints being hit.

What I observed was that the component was created twice. The first time, your token was passed correctly, the OnInitialized was called, and the data was collected from your server via the WeatherForecastService. The second time, the OnInitialized was called, as it was a new instance, no token was passed to the new WeatherForecastService instance, and you obviously received a 401 response, as you should. This is because prerendering is enabled by default (more information on render modes here: ASP.NET Core Blazor render modes)

So when you navigate to the WeatherInteractive page, I am seeing the following sequence of breakpoints being hit:

App.razor                // new instance and sets token
WeatherInteractive.razor // initialised
WeatherForecastService   // set token is passed
WeatherInteractive.razor // initialised (again) / new instance
WeatherForecastService   // new instance and empty token is passed

This is happening when NavManager is used (via the NavLink component) and also with a regular anchor html element.

This does not happen with StreamRendering. So when you navigate to the WeatherSsr page, I am seeing the following sequence of breakpoints being hit:

App.razor              // new instance and sets token
WeatherSsr.razor       // initialised
WeatherForecastService // set token is passed

If I set the render mode to no prerender:

@rendermode @(new InteractiveServerRenderMode(prerender: false))

... then I am seeing the following sequence of breakpoints being hit:

App.razor                // new instance and sets token
WeatherInteractive.razor // initialised
WeatherForecastService   // new instance and empty token is passed

I have not isolated why this is happening with your code and there is no simple work-around that I can see. I am not sure if this is a bug or by-design. Someone from Microsoft will have to chime in.

[wesleyscaldwell]

@gragra33 the construction of the TokenProvider is occurring twice, which is part of the issue.

The first time is for the server side rendered version of the page which is getting the access token set correctly, and is successfully making the HTTP call to the external service.

The second time is for the interactive client services, which as I understood it is what the circuit services accessor is supposed to help with. Maybe I have misunderstood what this is for. As this is creating a new version of the TokenProvider, rather than using the existing one that was populated in the App component, it provides a null access token and gets a 401 (Unauthorized) back from the external service. As I mentioned in the issue though, I am never seeing the CreateInboundActivityHandler method called so I may be doing something wrong here.

Ideally when the Blazor Hub receives a message I'd be able to just grab the token from the user's HttpContext, but the documentation makes it clear this is not safe to do in an interactive context. This is why I'm trying to follow the guide to get the TokenProvider working.

One approach I have tried which does seem to work is using the IHttpContextAccessor in the CircuitHandler.OnCircuitOpenedAsync to populate the TokenProvider, however I am not sure from the documentation about IHttpContextAccessor whether this is considered safe to do so ideally would like some clarification from someone very familiar with the Blazor hub if this is a safe thing to do or not.

This is the exact issue I am having. And I am new to blazor, not new to asp.net or DI. but it also seems like a lot of this is very new in Blazor so finding information has been difficult. The result i was hoping for is that the scope of the prerender or the scope of the http request that runs through the middleware would be the same scope that is then used on the interactive rendering side. But that is not the case.

Currently, I'm thinking the only option I have is to register a singleton token class keyed on some value from the user or cookie to then retrieve the token instance based on that key value. But obviously any custom token handle carries security risks.

Let me know if y'all found any solutions to this.

[gragra33]

@RobJDavey @wesleyscaldwell There is this recent blog post Per-User Blazor 8 State by @rockfordlhotka. I have not tried this, due to a recent emergency that we are still resolving, however this looks like a possible interim solution until Microsoft releases one.