Keycloak, Angular, and the BFF Pattern
blog.brakmic.com
Keycloak, Angular, and the BFF Pattern
1–10 of 25 posts
Re: Keycloak, Angular, and the BFF Pattern
#2I 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.
Re: Keycloak, Angular, and the BFF Pattern
#3I 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 bac…
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?
Re: Keycloak, Angular, and the BFF Pattern
#4I 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 bac…
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.
Re: Keycloak, Angular, and the BFF Pattern
#5I 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 bac…
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 securi…
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.
Re: Keycloak, Angular, and the BFF Pattern
#6The 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"
Re: Keycloak, Angular, and the BFF Pattern
#7Earlier quoted context omitted.
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 securi…
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.
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.
Re: Keycloak, Angular, and the BFF Pattern
#8The 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 coord…
> 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?
Re: Keycloak, Angular, and the BFF Pattern
#9The 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 coord…
> 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?
Because some people like the native app experience better?
Re: Keycloak, Angular, and the BFF Pattern
#10BFF 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.