Thanks a lot for your answer Neil, as I am no expert (yet :-)) in security I was afraid to rely on redirect_uri for authentication of the client, but I will consider that option as more trustworthy now.
(it is also not very clear for me which part of the app can be regarded as the redirect_uri owner, the BFF or the loaded frontend SPA, but maybe it is not so important) If you had the two options for authentication of the frontend SPA client - the redirect_uri on the one hand, and the Basic authentication with client secret through the BFF on the other, which one would you recommend? On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.mad...@forgerock.com> wrote: > > Public clients are implicitly authenticated by their ownership of the > registered redirect_uri. This why it’s important to use a redirect_uri for > which ownership can be reasonably established, such as HTTPS endpoints with > exact URI matching. > > There are more things that can go wrong with that (see the security BCP), but > it can be made reasonably secure. > > — Neil > > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.slept...@gmail.com> > > wrote: > > > > > > I would like to add my reasons about the "Why are developers creating BFF > > for their frontends to communicate with an AS", > > with the objective to verify if they are valid. > > > > I need the client app. to be authenticated at the AS (to determine if it is > > a first-party app., for example). > > If we decide to implement our client as a frontend SPA , then we have no > > other option except through a BFF, as PKCE does not help for authentication. > > > > Or is it considered a bad practice to do that? > > > > Regards, > > Stoycho. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
