ch4mpy
commented
1 year ago The aim of the tutorials in this repo is not to detail why the BFF pattern should be applied or to expose an opinion on which is the best solution. It is to demo how to implement it with Spring for those who would like to.
I think you are quoting me from Stackoverflow where I could have written JS applications in a browser (but maybe I later wrote that one of the aims is hiding tokens from the browser?)
Your UI developer is right when he says that you can get rid of sessions with public clients, but this requires to expose tokens to Javascript (when sessions can be handled with http-only cookies hidden from Javascript).
Public oidc clients with PKCE are not considered a best practice any more for SPA. You might find this article useful (requires a registration, but once you provided an e-mail, you can download the PDF)
When a JS application does not run in a browser, I believe it is not much of a problem if it accesses OAuth2 tokens (provided that tokens are persisted it in a very safe place, not accessible to any other program).
dreamstar-enterprises
First off great work with this repo !
We've been using Spring Cloud Gateway as a BFF for many years (when it was still called Zuul) to serve both backend microservices and single page application frontends because it allows us to free to UI from any security related concepts.
The UI is protected by the BFF (the gateway configured as an oauth2 client with authorization code).
So the UI gets a free "redirect to login page when there is no authenticated user", and Spring Cloud Gateway is great at converting authenticated users with an http session to oauth2 tokens to the underlying backend services (keeping the tokens away from the frontend).
We've really liked this approach as it simplifies UI development a lot.
However a couple of days ago I had a discussion with a new UI developer who never used this approach and was more familiar with using public oauth2/oidc clients with PKCE.
I myself (as a backend developer) am not a big fan of that approach as don't like the UI having intimate knowledge on how we do security. I much prefer offloading that to the gateway. But I wanted to hear him out.
I noticed the following in your README that gave me warm fuzzy feeling :) :
There is a big trend toward this pattern because it is considered safer than JS applications configured as OAuth2 public clients as access tokens are:
Do you have any references to that ?
The UI developer is still not convinced this is the correct path :) He does give some arguments
Anyway great job with this repo !