6.1.4.3 Suggestion: change text and remove significant burden

[damienbod]

6.1.4.3.

Additionally, this pattern requires all interactions between the JavaScript application and the resource servers to be proxied by the BFF, which puts a significant burden on the server-side component.

I usually use the BFF architecture without requiring a downstream API or a resource server and thus no proxy is required. My server logic is deployed as part of the BFF server application.

[aaronpk]

That sounds like that falls under the "Not Using OAuth" model: https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#name-single-domain-browser-based

[damienbod]

Hi @aaronpk yes it does sound like this, but I'm a bit confused because this is in the "Discouraged and Deprecated Architecture Patterns" I still use OIDC (Confidential client Code flow with PKCE)

This is in effect the BFF without a downstream API. If I need a downstream API, then I add a proxy and request the scope when required. I see the proxy, downstream API as an add-on to the BFF.

[aaronpk]

Can you elaborate on that? Are you using OIDC only for user authentication, e.g. no access tokens involved then? I'm trying to figure out how your use of OIDC/OAuth fits in when there is no API.

[damienbod]

Yes. The UI and the backend are authenticated as one using OIDC against any third party IDP etc. The session is stored in the form of a cookie as described in the doc. The APIs uses cookie authentication like the BFF. The backend APIs implement the business logic directly and there is no need for further API calls to different domains. Authz still needs a solution. If I need to use separate APIs on different domains, then I implement OAuth and add new scopes as required. At this point I would add the proxy, or just implement a Http Client. I don't always require a delegated user access token for the downstream APIs. I usually get an AT back from the OIDC server and can persist the claims to the cookie session as required.

So this is the BFF pattern described in section 6.1.1. The resource server part is not separated "always" from the BFF part, only when required.

This removes the "significant burden on the server-side component"

Section 6.1.2.4. Deployment Scenarios already mentions this pattern as well:

Serving the static JavaScript code is a separate responsibility from handling OAuth tokens and proxying requests. In the diagram presented above, the BFF and static web host are shown as two separate entities. In real-world deployment scenarios, these components can be deployed as a single service (i.e., the BFF serving the static JS code), as two separate services (i.e., a CDN and a BFF)

[philippederyck]

@aaronpk This discussion is related to our discussion when we restructured the document. The "no oauth" model is indeed valid and would just rely on a session between the frontend and the "API" to keep track of user's authentication state.

Back then, we weren't sure if this was discouraged, but agreed that it is not a core pattern of this spec, since it focuses on API-access with access tokens.

Two options: Either we rename this entire section (not my favorite), or we move the "no oauth" pattern upwards to section 4.

Let me know what you think

[aaronpk]

This sounds like what's described in 6.1.2.4

an application relying on both internal and external resource servers can choose to host the internal resource server alongside the BFF. In that scenario, requests to the internal resource server are handled directly at the BFF, without the need to proxy requests over the network.

The intent of the "significant burden" line is to capture the difficulty in deploying this pattern at scale. Perhaps there is a better way to phrase it. The same difficulty applies whether the resource server is internal to the backend or if it calls external resources. The point is you have to deal with either more network traffic or doing things like geographically distributing your databases.

[philippederyck]

I have proposed a slight rewording to resolve this issue according to comments made by @aaronpk and @damienbod

[aaronpk]

Thank you, closing as PR #36 resolves this.