Keycloak, Angular, and the BFF Pattern

This is very true! In practice I have seen that it is exceedingly difficult to write the GraphQL "sinks" (I don't recall the exact term) that can intelligently handle things like batching and understanding things like pre filtering, where one service in the composed call could and should be performed first to limit the result set. YMMV, in my experience it can be simpler to be more explicit about these things, especially when in "true" BFF the client team is also responsible for their immediate backend, which can give them that flexibility, at the cost, perhaps, of more boilerplate.

This is my take as well. Localstorage isn't the wild west anymore with regards to cross-site access (or even subdomain access) in modern browsers.

His mission statement up front is just... wrong (and as an aside, I like KeyCloak, there's nothing wrong with it, I auth several services I host with it). But to be exceptionally clear - the following is bullshit:

> Our goal? Design an application that never stores sensitive data in the browser.

Why bullshit? He then goes ahead and stores a cookie in the browser which his BFF happily upgrades to an access_token and makes requests with.

So his cookie is just his new token. Full fucking stop. Still sitting right there in the browser.

Are there reasons to prefer a cookie over doing something like keeping an access_token? Yes, although they're not as convincing as one might hope. They're certainly not as convincing as this article makes them out to be.

Generally speaking - the argument is that an HTTP-only cookie can't be read by javascript, preventing vulnerability to XSS. There is truth here that ex-filtrating an HTTP cookie is harder, but it doesn't remove any XSS vulnerabilities. All it does is add a marginal level of complexity: Instead of taking your token and doing stuff later, they just script the interaction they would have performed and put it in the XSS payload up front. It all runs on your client, which happily sends that cookie along for the ride. Marginally more complicated, absolutely doable, still completely hacked.

---

IMO there are really only two reasons to prefer a BFF:

1. Your client has needs that don't mirror the structure of the api you're accessing. Your bff can consolidate and simplify the api that the client has to consume, while also ensuring that you can handle breaking upstream api changes without needing to redeploy clients (the later is not a huge deal for websites, but IS a big deal for items that need to pass store review on redeploy - like mobile apps or browser extensions, and also for things that are technically complex to deploy - like enterprise desktop software)

2. You can reduce the available footprint of the API beyond the default scopes of your access_token. This is the only real security win - period. If you build a client that never needs to touch billing endpoints in the API... don't ever expose them in the BFF. You can limit the blast radius of an attack to things the client should be doing, even if the token would have allowed other, more dangerous, things. This is usually a sign of poorly implemented token scopes, but if that's out of your control - this is a viable solution.

In a lot of cases - the extra complexity just isn't worth it. Prefer using tooling that makes XSS difficult (React is genuinely pretty solid by default here, but you need to be careful with libraries and still enforce that you're not allowing dangerous calls). Prefer using SameSite and CORS with an HTTP-only cookie by default from your auth provider if you control the whole stack and can configure uri allowlists (esp if you're only authing across subdomains).

This is a really interesting reply, thanks for taking the time to compose it. As a soundcloud user, I actually noticed little things like how difficult the playlist loading problem might be and wondered precisely about how the client was getting updates as I scrolled. Interesting to know a bit more about the backend design.

I suppose I’m wondering still, in your example, why georestrictions couldn’t have just been an api feature in the list service vs both pieces of data needed to be fetched and reduced by a third service (and duplicate that logic across clients). I also work at a large company though, so I can see how “backends owned directly by client teams” is a path one might prefer when dealing with other teams with e.g. other priorities.