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 - ruclips.net/video/8FvN5bhVYxY/видео.html (info about jwt) handling jwt in oatuh - ruclips.net/video/0uSwPdYOm9k/видео.html (how to store tokens in database) refreshing tokens - ruclips.net/video/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?
![NLE Choppa - Or What ft. 41 (Orchestra Mix) [Official Music Video]](http://i.ytimg.com/vi/biOFASEgSOM/mqdefault.jpg)
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
Thank you very much for your videos, Anton!
thank you for watching!
Good Video, does 'Miro' pay you for the display? They should if they don't :)
they don't and damn right they should! Like comment on this: twitter.com/anton_t0shik/status/1617927460989067265
This needs a talk on BFF implementation spec
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.
I now feel imposter syndrome. lol
Hi, do you think that keeping jwt in cookie is a good idea or there is better and safer approach?
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 - ruclips.net/video/8FvN5bhVYxY/видео.html (info about jwt)
handling jwt in oatuh - ruclips.net/video/0uSwPdYOm9k/видео.html (how to store tokens in database)
refreshing tokens - ruclips.net/video/EC69dEspO64/видео.html (how to refresh tokens in the background)
@@RawCoding Ok cool, thanks for the answer
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.
Awesome
so migrating users from my app to something like auth0 is bad idea?
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?
@@RawCoding ok now that makes sense to me
I found the video to be difficult to follow because of all the drawings that were done and later removed. :(