How do you secure a Single-Page Application without storing tokens in the browser? The answer lies in the Backend-for-Frontend (BFF) pattern. This architectural approach shifts authentication complexity to the backend, keeping your frontend simple and secure. Let’s explore how it works and why it’s become the gold standard for SPA security.
This is a big topic, so I’ve split it into multiple parts. You can jump to the section you need, but for background and context, it’s best to start with part 1:
Part 1 – Introduction
Part 2 – Introducing the Backend-for-Frontend (BFF) pattern
Part 3 – Securing the Cookie Session (coming soon)
Part 4 – Implementing a BFF in ASP.NET Core (coming soon)
Part 5 – Automatic Token Renewal (coming soon)
Part 6 – Securing the BFF using CORS (coming soon)
Part 7 – Introducing the Duende BFF Library (coming soon)
The Backend-for-Frontend Pattern
Security experts and major OIDC providers increasingly recommend moving authentication out of the browser entirely. This approach is called the Backend-for-Frontend (BFF) pattern, and it’s becoming the standard for securing modern SPAs.
This is a prescription these days, not just an optional pattern that exists out there. The security landscape has evolved to the point where storing tokens in the browser is no longer considered acceptable for production applications, making the BFF pattern essential rather than optional.
The core idea is straightforward: instead of your React, Angular, or Blazor app handling OpenID Connect flows and managing tokens, a dedicated backend component (the BFF) takes complete responsibility for authentication.
Here’s how it works:
- The browser communicates with the BFF using a simple session cookie.
- The BFF handles all OpenID Connect interactions with your identity provider.
- The BFF stores tokens securely on the server side.
- When your SPA needs data, the BFF calls backend APIs using the stored tokens.
The BFF acts as an authentication proxy: your frontend gets the user experience of being “logged in” through a session cookie, while the BFF handles all the complex OIDC flows and token management behind the scenes.
Where does the BFF pattern come from?
The Backend-for-Frontend pattern didn’t start as a security solution. It originally emerged from the microservices world to solve a different problem: how to efficiently serve multiple types of client applications.
The core idea was simple but powerful: instead of forcing mobile apps, web browsers, and desktop applications to all use the same generic API, we can create dedicated backend services tailored to each client’s specific needs.
This approach solved several problems:
- Optimized data delivery:
Each client received exactly the data format and structure it needed. - Simplified frontends:
No more complex data transformation logic in client applications. - Clear separation of concerns:
Backend teams could optimize for specific client requirements.
This made the frontend simpler and more efficient, since it received exactly the data and structure it needed. It also helped separate any security concerns between different parts of the system.
This evolution makes perfect sense: if we can create specialized backends to meet data needs, why not create specialized backends to meet security needs? The BFF is like having your authentication specialist that lets your React, Angular, or Blazor app focus purely on user experience.
The Backend-For-Frontend Pattern in Practice
Now let’s see how this works in practice. With the BFF pattern, we move all authentication logic out of the frontend. Your SPA no longer needs to handle OIDC flows or manage tokens. Instead, a dedicated backend component manages all security concerns.
The BFF acts as a confidential client to your identity provider, which means it can securely store client secrets and handle the full OIDC flow. Your browser never sees tokens or handles the complex token exchange protocols.
This architectural shift unlocks powerful security advantages:
- Session Cookie Security:
The browser communicates with the BFF using a simple session cookie. This allows us to leverage strong, battle-tested browser security features, like:- HTTP-only cookies – JavaScript cannot access the session cookie.
- SameSite protection – Prevents cross-site request forgery attacks.
- Secure flag – Ensures cookies only travel over HTTPS.
- Reduced Attack Surface:
With tokens stored securely on the server, we eliminate major attack vectors, like: - No XSS token theft – Malicious scripts can’t steal what isn’t there.
- No token exposure – Browser developer tools won’t reveal sensitive tokens.
- Simplified frontend – Less security-critical code to review and maintain.
This creates a robust and yet simpler security perimeter that’s difficult to breach:
The Duende BFF Framework
Before we dive into building our own implementation, it’s worth mentioning that a production-ready solution already exists, and that’s the Duende.BFF security framework. This commercial product, developed by the team behind Duende IdentityServer, is currently the only dedicated BFF framework available for ASP.NET Core that I am aware of.
So why build our own instead of using Duende.BFF?
There are three key reasons:
- Learning and Understanding:
Building a BFF from scratch reveals the underlying security principles and common pitfalls that frameworks often abstract away. When you understand how authentication flows work at a fundamental level, you can make better architectural decisions and troubleshoot issues more effectively. - Practical Knowledge:
Working through the implementation details gives you the confidence to customize, extend, or debug BFF behavior in your own applications. This hands-on experience is invaluable when dealing with security-critical code. - Universal Skills:
Understanding the fundamentals gives you confidence and knowledge when working with any BFF implementation, whether it’s an existing solution like Duende.BFF or a custom implementation that you build yourself.
For production applications, definitely consider Duende.BFF if it fits your budget and requirements. For learning and understanding the core concepts, building your own implementation provides deeper insights.
For a comprehensive introduction to the Duende BFF framework, I recommend watching ‘Token Management: Applying the Duende Backend for Frontend (BFF) Security Framework‘ by Erwin van der Valk.
What's Inside a BFF?
Now that we understand why BFF is valuable, let’s look under the hood. A typical BFF implementation consists of two core components that work together to provide secure and seamless authentication:
- Session Management:
This component handles the complete OpenID Connect authentication flow with your identity provider. It manages the login process, issues secure session cookies to the browser, and stores access and refresh tokens safely on the server. Think of it as your authentication orchestrator; it keeps users logged in and handles token lifecycle management entirely behind the scenes. - API Proxy:
This component acts as a secure gateway between your SPA and backend APIs. When your frontend makes API calls, the proxy uses the session cookie to identify the user, retrieves the appropriate access token from storage, and forwards the request to the target API with proper authentication headers attached.
These two components work together seamlessly, allowing the session management component to establish trust with the browser, while the API proxy leverages that trust to make authenticated calls on the user’s behalf.
What’s next
Now that we understand how BFF works architecturally, it’s time to dive into the security details. In Part 3, we’ll explore how to properly secure the session cookie that travels between your browser and BFF. (Coming soon)
