# Backend For Frontend (BFF) Security Framework

> A comprehensive security framework for securing browser-based frontends with ASP.NET Core backends

The Duende.BFF (Backend For Frontend) security framework packages the necessary components to secure browser-based frontends (e.g. SPAs or Blazor applications) with ASP.NET Core backends.

Duende.BFF is free for development, testing and personal projects, but production use requires a license. Special offers may apply.

The source code for the BFF framework can be found on GitHub. Builds are distributed through NuGet. Also check out the samples.

[GitHub Repository ](https://github.com/DuendeSoftware/products/tree/main/bff)View the source code for this library on GitHub.

[NuGet Package ](https://www.nuget.org/packages/Duende.BFF)View the package on NuGet.org.

## Getting Started

[Section titled âGetting Startedâ](#getting-started)

Currently, the most recent version is 4 (preview 2). If youâre upgrading from a previous version, please check our [upgrade guides](/bff/upgrading).

If youâre starting a new BFF project, consider the following startup guides:

* [Single frontend BFF](/bff/getting-started/single-frontend/)
* [Multi-frontend BFF](/bff/getting-started/multi-frontend/)
* [Blazor](/bff/getting-started/blazor/)

## Background

[Section titled âBackgroundâ](#background)

Single-Page Applications (SPAs) are increasingly common, offering rich functionality within the browser. Front-end development has rapidly evolved with new frameworks and changing browser security requirements. Consequently, best practices for securing these applications have also shifted dramatically.

While implementing OAuth logic directly in the browser was once considered acceptable, this is no longer recommended. Storing any authentication state in the browser (such as access tokens) has proven to be inherently risky (see Threats against browser based applications). Because of this, the IETF is currently recommending delegating all authentication logic to a server-based host via a Backend-For-Frontend pattern as the preferred approach to securing modern web applications.

## The Backend For Frontend Pattern

[Section titled âThe Backend For Frontend Patternâ](#the-backend-for-frontend-pattern)

The BFF pattern (Backend-For-Frontend) pattern states that every browser based application should also have a server side application that handles all authentication requirements, including performing authentication flows and securing access to APIs.

The server will now expose http endpoints that the browser can use to login, logout or interrogate the active session. With this, the browser based application can trigger an authentication flow by redirecting to a URL, such as /bff/login. Once the authentication process is completed, the server places a secure authentication cookie in the browser. This cookie is then used to authenticate all subsequent requests, until the user is logged out again.

The BFF should expose all APIs that the front-end wants to access securely. So it can either host APIs locally, or act as a reverse proxy towards external APIs.

With this approach, the browser based application will not have direct access to the access token. So if the browser based application is compromised, for example with XSS attacks, there is no risk of the attacker stealing the access tokens.

As the name of this pattern already implies, the BFF backend is the (only) Backend for the Frontend. They should be considered part of the same application. It should only expose the APIs that the front-end needs to function.

## 3rd party cookies

[Section titled â3rd party cookiesâ](#3rd-party-cookies)

In recent years, several browsers (notably Safari and Firefox) have started to block 3rd party cookies. Chrome is planning to do the same in the future. While this is done for valid privacy reasons, it also limits some of the functionality a browser based application can provide. A couple of particularly notable OIDC flows that donât work for SPAs when third party cookies are blocked are OIDC Session Management and OIDC Silent Login via the prompt=none parameter.

## CSRF protection

[Section titled âCSRF protectionâ](#csrf-protection)

There is one thing to keep an eye out for with this pattern, and thatâs Cross Site Request Forgery (CSRF). The browser automatically sends the authentication cookie for safe-listed cross-origin requests, which exposes the application to CORS Attacks. Fortunately, this threat can easily be mitigated by a BFF solution by requiring a custom header to be passed along. See more on CORS protection.