[HN Gopher] Keycloak, Angular, and the BFF Pattern
___________________________________________________________________
Keycloak, Angular, and the BFF Pattern
Author : brakmic
Score : 31 points
Date : 2025-01-26 11:03 UTC (2 days ago)
(HTM) web link (blog.brakmic.com)
(TXT) w3m dump (blog.brakmic.com)
| malwrar wrote:
| I don't understand the benefit of adding this intermediate
| component vs just writing frontend code to interact with the APIs
| you'd otherwise already be calling. An HTTP server with sessions
| placed between clients and internal systems makes sense and is
| standard, but the weird callback-style "remote control" system
| seems completely unnecessary and inefficient to me. I don't think
| client logic being married to some backend vs the client itself
| makes any real guarantees about functionality being maintained
| either, it just adds a new location where code needs to be
| changed when something upstream changes.
| abraae wrote:
| Looking forward to enlightening replies to your question, I
| don't get it either. Keycloak APIs are already hardened, how is
| security provably increased by creating a new, far less tested
| access layer for the browser to use?
| TobbenTM wrote:
| I think the main attack vector they are trying to protect
| against is XSS attacks. If a malicious actor manages to inject
| client side code, there's nothing preventing them from
| exfiltrating tokens and gaining persistent user access. This
| because there is no Secure Enclave to store tokens in in
| browsers. The bff pattern can solve this by using HTTP only
| cookies, keeping all session tokens on the server. For high
| security scenarios like banks and health it makes sense, but
| there are so many more attack vectors that it's not gonna cover
| it all.
| evrflx wrote:
| With an XSS exploit it is game over, you control the browser.
| Adding more complexity and opening up the possibility of CSRF
| exploits with BFF does not look like a good trade off to me.
| TobbenTM wrote:
| You don't open up for CSRF attacks if you use same site
| cookies, which I guess is part of why this pattern is
| seeing more use now.
| diurnalist wrote:
| The article imo misuses the term BFF a bit, but perhaps its
| meaning has evolved over time. I was at SoundCloud when BFF was
| being introduced as an important piece of the microservice
| architecture--this post explains the purpose well[0]. BFFs can
| enable you to build more general-purpose and domain-specific
| services with few assumptions as to how they are used and their
| callers. BFFs then provide a composition layer you can use to,
| e.g., call one service to get a list of tracks, then call an
| authorization service w/ the list of track IDs to get geo-
| specific distribution rules for them, and compose that together
| in one materialized presentation view for the clients of the
| BFF.
|
| Eventually I think there was some work to move to GraphQL,
| which can solve some of the same problems. But GraphQL is a
| technology, and BFF is more of a pattern. There is a later
| reflection on that blog that makes this distinction, which I
| only read today.[1] It makes another observation that I kind of
| forgot about, because it was hiding right in front of my face
| as a worker there:
|
| "The defining characteristic of a BFF is that the API used by a
| client application is part of said application, owned by the
| same team that owns it, and it is not meant to be used by any
| other applications or clients."
|
| The ownership model is indeed a big deal. In practice, it
| helped in many ways to have a sort of intermediate layer
| between the client applications and the rest of the
| architecture. For example, in the SoundCloud web application,
| when you load a page of playlists, only the first 5 tracks in
| the playlist are visible to the end-user. So the web BFF
| application had special logic to only partially load all the
| track metadata past track 5, which had significant impact on
| scalability and latency, especially when rendering a lot of
| playlists that had lots of tracks!
|
| [0]:
| https://philcalcado.com/2015/09/18/the_back_end_for_front_en...
| [1]:
| https://philcalcado.com/2019/07/12/some_thoughts_graphql_bff...
| steeeeeve wrote:
| The BFF pattern is just "mostly microservices dedicated to a
| particular client type".
|
| It makes sense when you have drastically different needs between
| a desktop client and a mobile client (or maybe for a kiosk client
| or POS interface)
|
| Hosting a microservice is cheap, it avoids unnecessary workload
| on backend data stores, and teams can operate with more autonomy
| if they don't have to cooperatively update APIs in coordination
| with other groups with differing priorities.
|
| This article really just reads like "I figured out how to do
| authentication with keycloak using OIDC"
| brtkdotse wrote:
| > The BFF pattern is just "mostly microservices dedicated to a
| particular client type".
|
| If you're building dedicated APIs for just one client you've
| come full circle and building a monolith with a bunch of extra
| step. Why not just build a good old web app at that point?
| lmz wrote:
| Because some people like the native app experience better?
| yearesadpeople wrote:
| BFF pattern is very much misunderstood, and very much over-used
| IMHO
|
| Perhaps most useful - in highly distributed systems - I've seen
| is when we require some kind of flow orchestration, where we
| wouldn't like the orchestration logic at the API implementation
| (or indeed require the downstream services to not have to
| consider different contexts).
|
| [edit] Quite useful when designing nice clean, dedicated, new
| APIs and having to deal with legacy systems (perhaps data
| pertaining to the shiney new API model is housed in a legacy
| model): a useful means to keep moving forward.
| sqoopd wrote:
| I'm linking this draft discussing BFF from oauth perspective.
|
| https://datatracker.ietf.org/doc/html/draft-ietf-oauth-brows...
___________________________________________________________________
(page generated 2025-01-28 23:01 UTC)