Duende BFF Security Framework V3 Release Candidate 1
Today, we’re happy to bring you the first Release Candidate for the next version of the Duende Backend-for-Frontend (BFF) Security Framework V3.
BFF (Backend-For-Frontend) solves security and development challenges for client-side developers using SPA frameworks like React, Angular, VueJs or Blazor by providing a dedicated backend to manage OAuth/OIDC interactions while enforcing a “no tokens in the browser” policy.
In this blog post, we’ll look at some new functionality and cover some aspects you should be aware of when upgrading.
What’s new?
Duende BFF Security Framework v3.0 is a significant release that includes:
- .NET 9 support
- Blazor support
- Several fixes and improvements
.NET 9 support
Duende BFF Security Framework v3.0 is designed for both .NET 8 (Long-Term Support) and .NET 9, offering improved performance, new features, and enhanced capabilities with ASP.NET Core hosting improvements, AI building blocks, and more.
Blazor support
Microsoft’s Blazor framework enables developers to build interactive web applications using C# and .NET, offering both server-side and client-side hosting models. However, implementing authentication in Blazor presents certain challenges. For example, managing authentication states consistently can be complex in split-mode scenarios, where rendering is divided between server and client.
To address these issues, the new Backend for Frontend (BFF) framework provides comprehensive support for authentication in Blazor applications. The BFF pattern centralizes authentication logic on the server side, creating a secure environment for managing user identities and sessions. As with other browser-based applications, the actual authentication logic is handled on the server by the Duende BFF Security Framework. On the client, the BFF ensures that the authentication state is in sync with the session on the server.
The following diagram shows how the BFF’s Blazor support works:
Blazor supports multiple rendering modes, which provides a lot of flexibility, but can also cause complexities when it comes to authentication. Especially in RenderMode.Auto
, which makes a component start as a server-rendered component, until the web assembly component is downloaded and it takes over rendering. The BFF security framework uses a different Server and Client AuthenticationStateProvider
, to unify the authentication experience.
Fixes and improvements
- Prevent log warning when expected duplicate key constraint is violated. #1763
- Signout on refresh token expire #1803
- Bumped version of Duende.AccessTokenManagement to 3.2.0 #1804
Breaking changes
- Bff YARP proxy improvements #1734 (With many thanks to @ArturDorochowicz for bringing this issue to our attention and providing a solution direction)
- AddAddEntityFrameworkServerSideSessionsServices in Duende.Bff.EntityFramework/Configuration/BffBuilderExtensions.cs #1695
- Async GetUserClaims, GetManagementClaims #1702
- Consolidating ClaimRecord and ClaimLite #1697
Upgrading from V2 to V3
If you rely on the default extension methods for wiring up the BFF in your applications, V3 should be a drop-in replacement. There are, however, a few changes to be aware of.
Migrating from custom implementations of IHttpMessageInvokerFactory
In Duende.BFF V2, there was an interface called IHttpMessageInvokerFactory
. This was responsible for creating and wiring up YARP’s HttpMessageInvoker
. This interface has been removed in favor of YARP’s IForwarderHttpClientFactory
.
Read more about this change in the release notes.
Migrating from custom implementations IHttpTransformerFactory
The IHttpTransformerFactory
was a way to globally configure the YARP transform pipeline, for example, to replace defaults or to configure transforms for a single route.
In V3, the way the default endpoints.MapRemoteBffApiEndpoint()
method builds up the YARP transform has been simplified significantly. Most of the logic has been pushed down to the AccessTokenRequestTransform
.
Read more about this change in the release notes.
Removed method RemoteApiEndpoint.Map(localpath, apiAddress).
The Map
method was no longer needed as most of the logic had been moved to the MapRemoteBffApiEndpoint
and the DefaultTransformers
. The map method also wasn’t very explicit about what it did and a number of test scenarios tried to verify if it wasn’t called wrongly. You are now expected to call the method MapRemoteBffApiEndpoint
. This method now has a nullable parameter that allows you to inject your own transformers.
AccessTokenRetrievalContext properties are now typed
The LocalPath
and ApiAddress
properties used to be string
, but are now typed:
LocalPath
is now aPathString
ApiAddress
is now aUri
If you rely on these, for example for implementing a custom IAccessTokenRetriever
, you should adjust their usage accordingly.
AddAddEntityFrameworkServerSideSessionsServices has been renamed
If you used the method AddAddEntityFrameworkServerSideSessionsServices()
in your code, replace it with the corrected AddEntityFrameworkServerSideSessionsServices()
.
State provider polling interval options have been split into separate options for WebAssembly and Server
If you used BffBlazorOptions.StateProviderPollingInterval
or BffBlazorOptions.StateProviderPollingDelay
to configure different polling settings, you should now consider if this same setting applies to either Server, WASM or both. Set the appropriate properties accordingly.
Let us know your experience!
We’re excited with this release, ramping up for a full Duende BFF Security Framework V3 release in the coming weeks.
For more technical information about this release, please visit our Release Notes page on our Products repository. If you’re upgrading to the BFF Security Framework V3 release candidate, let us know how it goes!