in my company we implemented back end for front end because we integrated our project to an external project so bff became a client actually. the real backend has its own auth and our side has its own auth so we register our users to the other api and store their tokens in our side. when they are authorized in our side we match their token and just proxy it to the api that we integrated our app and get the response & modify it for our front end and return it
the only time ROPC will slide is if you own all components. www.scottbrady91.com/oauth/why-the-resource-owner-password-credentials-grant-type-is-not-authentication-nor-suitable-for-modern-applications
idea that one backend for frontend (bff) should depend on another at 8:50 defeats the whole purpose of bff pattern? In my understanding, in such case it would be better to have separate identity provider that every bff can use, as in original sample. Sorry if I misunderstood your point of view, in fact this video is hard to follow ;)
> idea that one backend for frontend (bff) should depend on another at 8:50 defeats the whole purpose of bff pattern? 1. BFF can be used in 2 ways that I know 1.1 firstly aggregate access to backend components (which can be on a private network), so your frontend is talking to a single backend rather than multiple (nothing to do with auth). 1.2 extending 1.1 - you are proxying all your requests but also holding authentication obtained from other components (in this situation the backend infrastructure may not belong to you) 2. Having a 2nd app to access the API is okey (look at github and multiple UI client libraries, it's multiple views/controllers in to the same data) the 2nd app will need to get and store the tokens hence it'll have it's own Backend. Further more - how many components do you want to configure? before we'd have to configure the external bff with all the api's and external oidc servers, after turning the local BFF in to an authentication server you'd only need to configure it in 1 place. > in such case it would be better to have separate identity provider that every bff can use, as in original sample. 1. saying the original sample was an identity provider is a bit of a stretch, mainly for being able to produce multiple login screens & not wrapping external authentication sessions, the BFF is orchestrating all of it. 2. "better" is questionable (try to articulate some actual reasons) multiple infrastructure components comes at a cost - it's okey to have a BFF play both roles of Client and Auth Server, or the Backend can be the API and Auth Server. In fact a single component playing all 3 roles is the default - you need to give good reasons to split them out. > Sorry if I misunderstood your point of view, in fact this video is hard to follow ;) that's why I answer comments hopefully it makes sense, thank you for asking the question.
it's not bad, you are exchanging convenience for functionality. if you store them in a cookie, the cookie get's bigger and you don't have access to them from the server which means you can't refresh them. if you want to know more: what and how of jwt - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-8FvN5bhVYxY.html (info about jwt) handling jwt in oatuh - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0uSwPdYOm9k.html (how to store tokens in database) refreshing tokens - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EC69dEspO64.html (how to refresh tokens in the background)
what is backend for frontend means is it another backend the frontend call before it calls the actual backend that contains the business logic if so why would we do two backends ?
He used "Backend" to refer to the domain logic. To make sense put a BFF on de design, this "backend" must be a set of distributed services, like microservices.
It largely depends on what your business goals are, but what made you think that? I've talked about not duplicating user entities if you don't need to - there is identity management and authentication, if something is already managing identities externally why do you need to do it again?
