BFFv4: Can't use IClientCredentialsTokenManager in a backgroundservice/hosted service

[twenzel]

I want to use the IClientCredentialsTokenManager to get a configured AccessToken (Instead of retrieving and caching it on my own).

But since I added the BFF services it won't work anymore.

Resolving the IClientCredentialsTokenManager instance from the IServiceProvider produces an error: "Not running in a http context".

at Duende.Bff.DynamicFrontends.CurrentFrontendAccessor.get_Context() in /_/bff/src/Bff/DynamicFrontends/CurrentFrontendAccessor.cs:line 13
   at Duende.Bff.DynamicFrontends.CurrentFrontendAccessor.TryGet(BffFrontend& frontend) in /_/bff/src/Bff/DynamicFrontends/CurrentFrontendAccessor.cs:line 19
   at Duende.Bff.DynamicFrontends.Internal.BffAuthenticationSchemeProvider.GetBffAuthenticationScheme(String name) in /_/bff/src/Bff/DynamicFrontends/Internal/BffAuthenticationSchemeProvider.cs:line 39
   at Duende.Bff.DynamicFrontends.Internal.BffAuthenticationSchemeProvider.<GetSchemeAsync>d__4.MoveNext() in /_/bff/src/Bff/DynamicFrontends/Internal/BffAuthenticationSchemeProvider.cs:line 34
   at Duende.AccessTokenManagement.OpenIdConnect.Internal.ConfigureOpenIdConnectOptions.GetConfigScheme(UserTokenManagementOptions options, IAuthenticationSchemeProvider schemeProvider)
   at Duende.AccessTokenManagement.OpenIdConnect.Internal.ConfigureOpenIdConnectOptions..ctor(IDPoPNonceStore dPoPNonceStore, IDPoPProofService dPoPProofService, IHttpContextAccessor httpContextAccessor, IOptions`1 userAccessTokenManagementOptions, IAuthenticationSchemeProvider schemeProvider, ILoggerFactory loggerFactory)
   at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)

What do I wrong?

[wcabus]

Can you share a bit more on what your setup is exactly? This is what I'm assuming, but do correct me where I'm wrong 🙂:

• You have an ASP.NET Core server-side application (Blazor ...?)
• This application needs to interact with another service using access tokens. This interaction runs in a background/hosted service, and you are using IClientCredentialsTokenManager from Duende.AccessTokenManagement to retrieve the access token.
• You recently added Duende.BFF. Since then (or since changing some of the configuration of services?), resolving IClientCredentialsTokenManager fails because it has a (sub)dependency on HttpContext or IHttpContextAccessor.

[twenzel]

I've a ASP.NET Core Blazor (webassembly) application
This application acts as BFF and talks to a API-Service. The most requests are done via the Remote-Api feature from Duende.BFF.

I've a new additional logic which is implemented as BackgroundService who also wants to talk to the external API. For this case it tries to use the IClientCredentialsTokenManager because the application has configured the ClientCredentialManagement from Duende.AccessTokenManagement.

[wcabus]

Why do you need a SignalR connection in the background job?

Isn't the background job interacting with the external API over HTTP just as you would do from the WASM part of your Blazor app? Because then, you can use the configured HttpClient in the background service. I'm confused why you would need a SignalR connection here.

[twenzel]

I want to have a "real-time" communication from my external API to the Blazor app.
So for this I've SignalR Hub the external API and a SignalRClient in the BFF (in the Background service). The Background service again uses a SignalR Hub if the BFF to send messages to all its client connections (WASM part of my blazor app).
This works great.

[wcabus]

Then I would rather suggest looking at configuring SignalR authentication between the BFF host and the API on a more global level (in your Program.cs or where you are configuring your services).

Perhaps you can add a separate OIDC scheme configured for client credentials flow to setup machine-to-machine authentication between the BFF Host and API for SignalR, then instantiate the SignalR client in the background service to flow the messages to the WASM clients.

This very much feels more like an architectural issue than a Duende.AccessTokenManagement one however, which is out of scope for support in this community.

[twenzel]

You're right.
But again the main sole issue I facing is, that I can't use the IClientCredentialsTokenManager in BackgroundService (In any context where no HTTP context is available).
I even can't get a HttpClient from IHttpClientFactory configured with AddClientCredentialsTokenManagement.

[OskarKlintrot]

Perhaps you can add a separate OIDC scheme configured for client credentials flow to setup machine-to-machine authentication between the BFF Host and API for SignalR

Would you mind provide a sample for how to register different schemes when using ConfigureOpenIdConnect in v4?

[OskarKlintrot]

We run into this as well. We have a BackgroundService running to update an in-memory cache by retrieving data via http calls. When trying out v4 CurrentFrontendAccessor throws "Not running in a http context":

System.InvalidOperationException:
   at Duende.Bff.DynamicFrontends.CurrentFrontendAccessor.get_Context (Duende.BFF, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null: /_/bff/src/Bff/DynamicFrontends/CurrentFrontendAccessor.cs:13)
   at Duende.Bff.DynamicFrontends.CurrentFrontendAccessor.TryGet (Duende.BFF, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null: /_/bff/src/Bff/DynamicFrontends/CurrentFrontendAccessor.cs:19)
   at Duende.Bff.DynamicFrontends.Internal.BffAuthenticationSchemeProvider.GetBffAuthenticationScheme (Duende.BFF, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null: /_/bff/src/Bff/DynamicFrontends/Internal/BffAuthenticationSchemeProvider.cs:39)
   at Duende.Bff.DynamicFrontends.Internal.BffAuthenticationSchemeProvider+<GetSchemeAsync>d__4.MoveNext (Duende.BFF, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null: /_/bff/src/Bff/DynamicFrontends/Internal/BffAuthenticationSchemeProvider.cs:34)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter.GetResult (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at Duende.AccessTokenManagement.OpenIdConnect.Internal.ConfigureOpenIdConnectOptions.GetConfigScheme (Duende.AccessTokenManagement.OpenIdConnect, Version=4.0.0.0, Culture=neutral, PublicKeyToken=e7877f4675df049f)
   at Duende.AccessTokenManagement.OpenIdConnect.Internal.ConfigureOpenIdConnectOptions..ctor (Duende.AccessTokenManagement.OpenIdConnect, Version=4.0.0.0, Culture=neutral, PublicKeyToken=e7877f4675df049f)
   at System.RuntimeMethodHandle.InvokeMethod (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Reflection.RuntimeConstructorInfo.Invoke (System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)

[wcabus]

After reviewing this stack trace and trying to reproduce the issue locally, there indeed seems to be an issue when trying to resolve an HTTP client from a IHttpClientFactory when the BFF host is configured to support multiple frontends.

This issue can occur both when trying to resolve an HTTP client directly using IHttpClientFactory in a hosted service, or when trying to use the IClientCredentialsTokenManager which uses IHttpClientFactory at some point as well.

I've informed the engineering team to see if there's a workaround possible, or what is needed on the BFF side to fix this issue.

[OskarKlintrot]

We don't use multiple front ends. Though, from my understanding, if you only use a single front end with v4, a "default" front end will be configured anyway (which makes perfect sense from a technical point of view).

[wcabus]

This issue should be resolved in the latest BFF v4 RC4 version: https://github.com/DuendeSoftware/products/releases/tag/bff-4.0.0-rc.4