BlazorWebAppOidcBffWebAuto, but with only InteractiveWebAssembly?

[Schoof-T]

Describe the issue

We are using Blazor Web App with only InteractiveWebAssembly (because of some limitations of external components we use) and we authenticate through OpenIdConnect.
We want to use the BFF pattern as explained in the documentation.

However, there is no sample for only InteractiveWebAsssembly, so we started with the BlazorWebAppOidcBffAuto sample and removed the .AddInteractiveServerComponents()

Locally on our development machines this all seemed to work fine, but once we deploy our application on our Kubernetes cluster we start running into issues.

• The logout (authentication/logout) doesn't work, the page returns a 500:

StatusCode: 500, BodyAsText: This form is being accessed with an invalid anti-forgery token. Validate the `IAntiforgeryValidationFeature` on the request before reading from the form.

• After x amount of time, it seems like the frontend 'forgets' your authentication. All the [Authorize] attributes return an unauthorized, and getting items from the claims await AuthenticationStateProvider.GetAuthenticationStateAsync(); returns nothing.

To Reproduce

Steps to reproduce the behavior:

1. Adjust the BlazorWebAppOidcBffAuto sample to only be InteractiveWebAssembly.
2. Deploy the application through: dotnet publish "${PROJECT}.csproj" -c Release -p RuntimeIdentifier=linux-x64
3. Try to authentication/logout endpoint.

Additional context

• DOTNET 10

Is InteractiveWebAssembly not supported with the sample codes, or there any different changes we need to do?

---

Issue Details

⚠ Do not edit this section. It is required for issue processing.

• Content Source: dotnet/blazor-samples
• GitHub Login: @guardrex

[guardrex]

Thanks for the question, @Schoof-T. I'll ping @halter73, our security guru who built the samples for these articles, to respond. I'll send him an email, too, to make sure that he sees this. Stand-by for his arrival to help ....................

UPDATE: Email sent. He should be along shortly to assist.

[guardrex]

Also, note that we ask devs to open new issues for us using the Open a documentation issue link at the bottom of the article, which places metadata into the issue for tracking and opens the issue on the documentation repo. I'll add the metadata manually to this, so no worries. CORRECTION: I'll open an issue for this if the article requires work to address this scenario.

[guardrex]

BTW ... It doesn't sound like you're using a common Data Protection (DP) key storage approach or using a sticky-session scheme where a user is always routed back to the same worker node when using the app. If you're using a cluster without using a common DP key repository (or sticky sessions), each worker node protects data with DP keys on each worker node ... i.e., one node can't decrypt data protected by a different node. There's more info on this in the DP area of the docs ...

https://learn.microsoft.com/aspnet/core/security/data-protection/configuration/overview

... with more info in other articles in that area ...

• https://learn.microsoft.com/aspnet/core/security/data-protection/implementation/key-storage-providers
• https://learn.microsoft.com/aspnet/core/security/data-protection/implementation/key-encryption-at-rest

If this is the problem that will require your attention, keep in mind that the worker nodes need the same app name for the DP system ... SetApplicationName API ... which is sprinkled into the coverage in a few spots. Sometimes, it trips folks up because they provision a common key storage location but they forget to set a common app name for the DP system.

[Schoof-T]

BTW ... It doesn't sound like you're using a common Data Protection (DP) key storage approach or using a sticky-session scheme where a user is always routed back to the same worker node when using the app. If you're using a cluster without using a common DP key repository (or sticky sessions), each worker node protects data with DP keys on each worker node ... i.e., one node can't decrypt data protected by a different node. There's more info on this in the DP area of the docs ...

https://learn.microsoft.com/aspnet/core/security/data-protection/configuration/overview

... with more info in other articles in that area ...

• https://learn.microsoft.com/aspnet/core/security/data-protection/implementation/key-storage-providers
• https://learn.microsoft.com/aspnet/core/security/data-protection/implementation/key-encryption-at-rest

If this is the problem that will require your attention, keep in mind that the worker nodes need the same app name for the DP system ... SetApplicationName API ... which is sprinkled into the coverage in a few spots. Sometimes, it trips folks up because they provision a common key storage location but they forget to set a common app name for the DP system.

Hi @guardrex, thanks for the responses. I appreciate the quick response!

Our cluster currently only runs one pod per application, and we are setting the DataProtection to our local redis as follows:

        var connectionMultiplexer = ConnectionMultiplexer.Connect(configuration.GetConnectionString("Redis"));
        builder.Services.AddDataProtection().PersistKeysToStackExchangeRedis(connectionMultiplexer, "DataProtection-Keys").SetApplicationName("AppName");

So I don't think that's the issue.

[guardrex]

Gotcha! Glad that we ruled that out for @halter73. He might have asked about it. It might matter for cookies that live past the session (in a sesson-less, session affinity-less CSR only app like this one).

As an aside, I'm going to add a little bit of coverage to the BWA+OIDC article anyway on the subject. It's probably just a matter of time before that does become a problem for someone new to ASP.NET Core or new to app development in general.

UPDATE: I have a PR now for him to look at, which reminds interactive SSR folks to enable session affinity and recommends a shared DP key ring for everyone, even with a CSR app. Again, I'm not sure if lingering cookies across uses of the CSR-focused app is a concern. @halter73 will let me know exactly what we should be telling devs on the PR (and perhaps here) WRT this type of app setup.

[guardrex]

I didn't hear back from Stephen. I just sent him an email.

... and note Stephen when you see this that the PR I put up isn't related to the problem that @Schoof-T is having. It just came up in discussion that we didn't have web farm/cluster guidance in our articles for DP/session affinity. That PR is just focusing on that at the moment.