Terminology concern: “Backend for Frontend (BFF)”

[tillsc]

The draft uses the term “Backend for Frontend (BFF)” for a component that terminates OAuth, manages tokens and sessions, and forwards requests to downstream APIs.

The concern is not the pattern itself, but the terminology.

In common architectural usage, a BFF is intentionally application- or frontend-specific, tightly coupled to a single UI, and not generic or reusable infrastructure.

The pattern described here is different:

• no UI- or application-specific logic
• stable, security-driven responsibilities
• realistically reusable across multiple frontends
• suitable for implementation as off-the-shelf API gateway functionality

While a BFF can perform these functions, they are not distinguishing characteristics: the same responsibilities can equally be fulfilled by a generic, reusable proxy component. As such, the described component no longer matches the defining property of a BFF.

This terminology mismatch may cause confusion around architecture, ownership, and responsibilities.

Possible mitigations:

• explicitly clarify that this is a security-focused, proxy-style pattern and not a UI-specific backend
• note the difference from the common architectural meaning of BFF
• consider more precise terminology (e.g. "frontend-facing OAuth proxy" or simply "proxy")

This would improve clarity without changing the technical substance of the draft.

[philippederyck]

I don't see it this way. While it is true that the BFF does not contain application-specific logic, it does contain an application-specific configuration. Each BFF instance will be configured with OAuth client credentials, and with a mapping for proxying endpoints to APIs. Furthermore, if you already have an application- or UI-specific BFF in place, you can easily augment it with these security responsiblities.

Comparing an OAuth BFF to an API gateway is tricky, since the BFF is decoupled from the APIs. An API gateway can be hit by numerous clients, so making this gateway act as a BFF to all of them would not make sense.

[aaronpk]

Agreed with Philippe. Additionally, "proxy" is also far too overloaded of a term that doesn't convey enough of the properties of what we are trying to describe in this document.

[tillsc]

Thanks, I understand the concern about terminology being overloaded.

However, my point is not that “proxy” would be a perfect or complete description of all properties discussed in the document. It is that the properties currently used to justify the term “BFF” are not distinguishing either.

Application-specific configuration (OAuth credentials, routing mappings, policies) is common for many infrastructure components and does not make a component application-specific in the architectural sense. Reverse proxies, API gateways, and identity components are routinely configured per application or frontend without being considered BFFs.

From an application architecture perspective, a BFF typically contains domain-specific logic tailored to the frontend's needs: aggregating data, transforming responses, or implementing frontend-specific business rules. The pattern described here contains none of these characteristics.

Likewise, the fact that an existing UI-specific BFF can be augmented with these security responsibilities reinforces the point that these responsibilities are orthogonal to what defines a BFF, not constitutive of it.

The concern, therefore, is not about finding a single perfect replacement term, but about avoiding the use of “BFF” for a pattern whose defining characteristics are generic, reusable, and infrastructure-oriented. Even if “proxy” is overloaded, using a term that implies frontend- or application-specific backend logic where none is required risks greater confusion.