Q&A

BFF and SPAs: Best Friends Forever

• By David Ramel
• 04/08/2026

Single-page applications helped define modern web development, giving teams a way to build rich, responsive interfaces with frameworks such as Angular, React and Blazor. But one of the architectural assumptions that long accompanied SPAs -- storing OAuth tokens in the browser -- has come under increasing scrutiny as developers confront the security realities of cross-site scripting attacks and the limitations of browser-based token handling.

That changing security landscape is the focus of BFF and SPAs: Best Friends Forever, an upcoming session at Visual Studio Live! @ Microsoft HQ. In the session, Christian Wenz will examine why the Backends for Frontends (BFF) pattern is gaining traction as a more secure alternative for SPA authentication, shifting token management from the browser to the server side through secure cookies and a dedicated backend layer.

For development teams, that shift is about more than revisiting old ideas. The BFF pattern reflects a broader industry move toward reducing the browser's exposure to sensitive authentication data while improving compatibility with modern browser security models. For organizations building or maintaining SPAs, it raises important questions about how authentication should work now, what risks remain in legacy approaches, and how difficult it is to migrate without disrupting existing applications.

Those are exactly the issues Wenz plans to address. A Microsoft MVP and CEO of Actition GmbH, Wenz is a consultant, software architect and entrepreneur specializing in web technologies and security. He has authored or co-authored more than 100 books and is also noted as the lead author of the Zend PHP certification, giving him a long-range perspective on how web application security practices have evolved.

Ahead of his July 29 session, we asked Wenz about why so many SPA teams still rely on browser-stored tokens, what the biggest misconceptions are around that model, and why he sees BFF as the most secure approach for authentication in modern single-page applications.

VisualStudioMagazine: What inspired you to present on this topic?
Wenz: I consider the BFF pattern to be the most secure approach for authentication single-page applications (SPAs), yet many of the web applications I'm auditing are using different patterns. Therefore I would like to spread information about the BFF approach, and discuss it with attendees.

What is the single biggest security risk introduced by storing OAuth tokens in the browser for SPAs?
Simply put: if you have cross-site scripting (XSS) in your app, your tokens are gone. Most of the time, those tokens are stored through the Local Storage API, which is a JavaScript API, so injected malicious script code can also access the token through it.

What misconception leads many teams to believe browser-based token storage is "good enough" today?
I have to give teams some slack: before BFF was the recommended pattern, the consensus was indeed to use a more or less complicated flow to attain a token, and then store it in the browser. And from then on, it's "never change a running system." But technology advanced, so you should really consider implementing the BFF pattern.

In simple terms, what does the BFF pattern change in how authentication flows are handled?
With the BFF pattern, the browser no longer stores the token; instead, a backend takes care of this. In the typical case of a SPA, the frontend issues a call to the specific backend; the backend then calls the actual API and appends the token to that call.

What is the most immediate security benefit teams gain after moving to a BFF approach?
When using the approach briefly described in the previous question, the client (or frontend) is using a cookie-based session to communicate with the server. Modern browsers can protect session cookies from being stolen, for instance through XSS. Therefore, just by looking at the security posture, the BFF approach is better than tokens in local storage.

What is the most common challenge developers face when migrating an existing SPA to BFF?
Getting BFF right, and securing it from other threats, such as CSRF (cross-site request forgery) is not trivial. I'll discuss pitfalls (and solutions) in my session, of course! Also moving from local token storage to a BFF solution requires some refactoring in the application, something that has not always been budgeted for.

Are there specific scenarios where adopting the BFF pattern might not be the right choice?
One scenario I see is legacy apps that are hard to migrate to a new pattern. In that case, I would intensify anti-XSS measures such as Content Security Policy, Trusted Types API, and others.

What is one practical first step a team can take to start transitioning from a token-in-browser model to BFF?
It depends a little bit on which framework or library has been used for the existing OAuth token flow. Some vendors already come with ready-to-use BFF implementations, but you'll learn all the important aspects to consider creating your own.

How can attendees learn more about this topic and prepare for your session?
If you have an existing single-page application or are working on one, that's all that's required. I'll dive into risks, countermeasures, existing solutions, and more.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $400 when you register by the May 15 deadline," said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.