Skip to main content

BFF Pattern and the Token-Protection Security Model

Overview​

BFF (Backend for Frontend) is a design pattern that places a dedicated server-side layer for a SPA (Single Page Application) and consolidates authentication and token management on the server. Because no access token or refresh token is ever handed to the browser, it structurally eliminates the SPA's biggest weakness: token theft via XSS.

The OAuth 2.0 Security Best Current Practice (RFC 9700) and the IETF "OAuth 2.0 for Browser-Based Applications" recommend the BFF pattern for browser apps that require elevated security.

Related documents

This document covers the security motivation and threat model of BFF. For a concrete .NET / YARP implementation, see BFF Pattern with YARP; for UI-asset hosting strategy, see BFF UI Hosting Strategy.

Why BFF: the risk of keeping tokens in the browser​

A traditional SPA obtains tokens via the Authorization Code + PKCE flow and keeps them in localStorage, sessionStorage, or memory, calling APIs with an Authorization: Bearer header. This approach carries the following risks.

RiskDescription
Token theft via XSSA token in localStorage can be read by any injected script via localStorage.getItem()
Token exposureTokens are visible in browser DevTools (Network / Application tabs)
Refresh token in the browserA long-lived refresh token in the browser is high-impact if exfiltrated
No client secretA SPA cannot safely hold a secret and relies on PKCE alone

BFF eliminates all of these by keeping tokens on the server only.

Public vs. Confidential Clients​

OAuth 2.0 clients fall into two types depending on whether they can safely hold a client secret.

  • Public client: cannot safely hold a secret. SPAs and native mobile apps. Requires PKCE to defend against authorization-code interception.
  • Confidential client: can safely hold a secret. Server-side apps.

Introducing a BFF turns the browser app from a "public client" into a confidential client running on the server. This enables strong client authentication with a client secret (defense-in-depth with PKCE).

BFF Structure​

The BFF is responsible for:

  1. Same-origin delivery: serves the SPA static files and the API proxy from the same origin (no CORS).
  2. OIDC authentication: runs the Authorization Code + PKCE flow server-side as a confidential client.
  3. Cookie / session management: issues HttpOnly/Secure/SameSite cookies (containing only an opaque session reference) to the browser; the tokens live in a server-side store.
  4. CSRF protection: cookie auth requires CSRF defense (see CSRF / SameSite / CSP).
  5. Reverse proxy: converts the cookie into a Bearer token when forwarding to the API, and handles expiry checks, automatic refresh, and rotation.

Threat model: what BFF prevents and what it does not​

The most important point for understanding BFF is the distinction between "token theft" and "session riding."

ThreatBFF effect
Token theft (exfiltration) via XSS✅ Prevented. Tokens are not in the browser; the HttpOnly cookie is unreadable by JS
Token exposure on the network✅ Prevented. Tokens exist only server-side
External API exposure✅ Reduced. The API is internal-only, funneled through the BFF
Session riding via XSS⚠️ Not prevented. The cookie is auto-sent, so an injected script can still call the API through the BFF
BFF is not a substitute for XSS prevention

BFF merely moves the threat from "token theft" to "session riding". If XSS succeeds, an attacker can operate the API in the victim's session even without stealing the token. Therefore a strict CSP (Content Security Policy) and fundamental XSS prevention remain mandatory.

Alignment with standards and best practices​

  • RFC 9700 (OAuth 2.0 Security BCP): recommends BFF for sensitive browser apps.
  • IETF "OAuth 2.0 for Browser-Based Applications": recommends not keeping tokens in the browser.
  • "Keep tokens on the server": this is also the simplest way to avoid needing token binding (DPoP / mTLS) — if tokens are server-side, there is no token to steal.

Summary​

  • BFF consolidates SPA token management on the server, structurally eliminating token theft via XSS.
  • It makes the browser app a confidential client authenticated by cookies (opaque session reference) plus CSRF protection.
  • BFF prevents token theft, but not session riding → CSP and XSS prevention are mandatory.
  • See the YARP-based implementation document for details.

References​