# When a backend-for-frontend is the right authentication boundary

> Choose between browser-held OAuth tokens and a BFF by tracing token exposure, cookies, CSRF, and deployment ownership.

Canonical URL: https://www.devobs.io/articles/browser-backend-for-frontend-auth-boundary/
By: Nina Patel
Published: 2025-06-01T21:37:59.944Z
Updated: 2026-09-05
Section: Architecture

Use a backend-for-frontend when your team controls the browser application and its backend, and keeping OAuth tokens out of browser JavaScript is worth operating a stateful security boundary. The browser then holds an application session cookie; the BFF performs OAuth flows, stores tokens server-side, and calls APIs. This reduces token exposure to injected JavaScript, but it replaces bearer-token handling with cookie and CSRF obligations.

## Draw the two request paths

In a token-holding SPA, the browser performs the authorization code flow with PKCE, receives tokens, and sends access tokens to APIs. It has fewer application hops and can call multiple resource servers directly. However, code running in the page shares the environment that uses those tokens. Storage choice changes persistence, not the fundamental exposure to malicious script executing in the origin.

In the BFF pattern, the browser redirects through the backend. The backend acts as the OAuth client, keeps refresh and access tokens away from JavaScript, and returns a cookie-backed session. API requests go to the BFF, which attaches an access token downstream. [RFC 10017: OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/rfc10017/) describes BFF and related architectures, including their security properties and deployment considerations.

Do not turn the BFF into an open proxy. Give it explicit routes, fixed upstream destinations, narrow methods, response-size limits, and the same authorization checks the API contract requires. Bind its server-side token record to the browser session and rotate the session identifier after login.

## Cookies move the threat boundary

Set session cookies with `Secure`, `HttpOnly`, an appropriate `SameSite` value, a narrow `Path`, and no broad `Domain` unless the design requires it. Because browsers attach cookies automatically, protect state-changing routes from cross-site requests. SameSite helps but is not a complete CSRF design for every redirect and same-site subdomain scenario. Use an anti-CSRF token or a strict origin check appropriate to the application, reject unsafe content types, and keep GET routes free of state changes.

The BFF must also defend its OAuth callback. Use authorization code plus PKCE, bind `state` to the initiating browser session, require exact redirect URI matching, and validate the issuer and token response. [OAuth 2.0 Security Best Current Practice](https://www.rfc-editor.org/rfc/rfc9700.html) consolidates current guidance including authorization response protections and sender constraints.

## Decide with operational facts

A BFF is a strong fit when the application handles valuable data, depends on long-lived delegated access, already has a same-team backend, and can route API traffic through it without unacceptable latency or bottlenecks. It is also attractive when APIs should never accept tokens from browser code directly.

A direct SPA remains reasonable for lower-value applications, independently deployed static clients, or ecosystems where browsers must call many third-party APIs and the team cannot operate the mediation layer. Use code flow with PKCE, keep tokens short-lived, minimize scopes and audiences, and treat the origin's script supply chain as part of the credential boundary.

If Ory fits the identity architecture, Ory Hydra provides OAuth 2.0 and OpenID Connect and Ory Network can integrate with an existing user-management system. That headless separation works well with a BFF because the application keeps control of its session and user experience while the authorization server handles the protocol. Evaluate Ory Network and a self-hosted Hydra deployment as distinct operational choices.

Write down five decisions before implementation: who owns the BFF, where tokens live, how CSRF is blocked, which upstream routes exist, and how sessions are revoked. Then build one login-to-API vertical slice and threat-model the exact cookie, redirect, and token path before migrating the rest of the application.

Apply outbound timeouts and cancellation as well, because abandoned browser requests should not leave authenticated downstream work running without a caller.

## Source references

- <https://datatracker.ietf.org/doc/rfc10017/>
- <https://www.rfc-editor.org/rfc/rfc9700.html>