Formally proving that you can't be authenticated to a service without actually holding some type of authentication token is trivial.
Whatever you replace it with (a short-lived access token, a session cookie, a JWT, or whatever else) becomes the authentication token — if you add other properties (like short expiry), you are mostly trading convenience for security (eg. people will get logged out, or you'll need to implement refresh token dance in your app).
So it's really confusing to me how can someone pretend that there is something you can do on the unsafe client side, because you really can't (sure, there are obvious things you shouldn't do, like keep a plain text password in a cookie or localStorage, but an auth token is pretty much the same thing other than expiry).
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"
I've looked over the code, and some things seem a little odd to me.
The article starts by mentioning how insecure the browser is, apparently even cookies aren't secure. But then the API to talk to the BFF uses.... a server-side session tracked via a client cookie. If the BFF is holding the oauth credentials, then someone could steal the client cookie to make requests to the BFF to do whatever it can do.
It's not impossible to secure the browser from having credentials stolen from inside it, but it can be tricky to ensure that when the browser sends the credential in the request it doesn't leak somehow.
There's some irony as OAuth has DPoP now which can reduce the usefulness of stolen in-flight credentials but that can't be used in this BFF setup because the browser client needs the private key to sign the requests.
Properly securing the browser content on a login page, or the subdomain handling authentication credentials is definitely a challenge, and many don't like having to eliminate/audit any 3rd party JS they include on the page. I can see the appeal of a solution like this, but the trade-off isn't great.
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.
I’m linking this draft discussing BFF from oauth perspective.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-brows...
I’m surprised that the author chose to configure a public OIDC client for this scenario. Part of the benefit of this pattern is that it’s possible to use a confidential client, since the BFF can securely hold the client secret.
And I thought it's best friends forever! SCNR
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.