I've read through all of the following RFCs:
[2]: RFC 8252: OAuth 2.0 for Native Apps (Note this includes not only mobiles apps but also desktop applications.)
[3] recommends the use of one of the following architectures for browser-based applications:
Backend For Frontend (BFF), in which the backend proxies all of the requests related to OAuth 2.0, including access to resource servers. No (unencrypted) token is exposed client-side.
Token-Mediating Backend (TMB), in which only the backend stores refresh tokens while access tokens are exposed client-side.
Browser-based OAuth 2.0 client, in which no backend is involed in OAuth 2.0. Every token is exposed client-side.
[3] also recommends the BFF pattern especially for sensitive applications:
This architecture is strongly recommended for business applications, sensitive applications, and applications that handle personal data.
On the contrary, [2] (throughout the RFC but especially in Section 4.1) only refers to the architecture where no backend is involed in OAuth 2.0, which conceptually corresponds to the Browser-based OAuth 2.0 client pattern above.
But why? I have these three questions:
Is it recommended to use the BFF pattern also for native applications?
Is there any formal source (such as another RFC) to support your answer?
Why does [2] not refer to the BFF pattern? Perhaps the reason is that the execution environment of native applications is much safer than that of browser-based applications, in which attackers can inject and execute malicious JavaScript codes, but I think theoretically it is also possible to do similar things for native applications (especially for desktop applications) by techniques such as binary patching or memory editing.
Is it recommended to use the BFF pattern also for native applications?
I would say no, but there are caveats that I attempt to explain below. BFF is an overloaded term. I would begin by understanding the execution environment and the problems you want a BFF to solve.
For a browser-based app, a BFF that issues secure cookies ensures that tokens cannot be exfiltrated and thus limits the impact of XSS exploits.
For a native app, I will use an example where you want to keep tokens returned to devices confidential, since that can also be a motivation for a BFF, to prevent the app or other parties from reading data in JWT access tokens.
Solutions to both could use backend components but there are major differences. Usually the term BFF is used in the context of browser based apps and not native apps.
Is there any formal source (such as another RFC) to support your answer?
The introduction to OAuth for Browser Based Applications points out the vast differences between execution environments between browser and native apps.
There are no IETF docs that discuss a BFF for Native Apps. But the docs on OAuth Token Introspection and JWT Response might be used in a native use case that requires BFF logic.
Why does [2] not refer to the BFF pattern?
To see why, let's look at the problems a BFF solves for browser-based applications, where a server component assists the frontend in its security:
A BFF can issue HTTP only cookies that the browser makes unavailable to JavaScript code. JavaScript also cannot see what is in access tokens, which keeps this data confidential.
The BFF can instruct the browser how to handle cookies, eg to apply SameSite=strict and CORS, so that the browser only allows cookies to be sent from code running in the app's precise origin.
Although you could use a BFF for a native app, you can't hide tokens or cookies from the app's code or dictate where the frontend can send them. Instead, a BFF for a native app might introspect opaque access tokens then forward JWT access tokens to APIs.
Summary
I think of a BFF solution as one that involves deploying an extra cookie issuing component per web app. You don't need to do that for native apps.
Where possible I would manage tasks like token introspection in an API gateway, to apply such logic to multiple APIs. Some people call that type of solution a BFF.