Correct it would never need to be used to authenticate a client, as a client is always offline and can directly use the backchannel. You would never need the front channel to authenticate a client, however you might need the front channel to authorize a client to access user resources offline. Is that what you are talking about, i.e. the offline refresh_token authorization code flow?
If yes, then the standard would be to use the authorization code flow requesting as you've mentioned. Although that flow already exists and well established, and without any issues, having a standard specifying how to communicate with the client doesn't seem to be useful, as you only need to pass an *auth code* and the *issuer* to the client. But since these endpoints are never exposed nor need to have interoperability between different owners (i.e. the owner of the front-channel is different from the owner of the back-channel), what's the benefit of specifying the explicit endpoints necessary for the BFF to have? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress <https://authress.io>. On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov <stoycho.slept...@gmail.com> wrote: > Thanks Warren, > > as I see you and Neil have the same idea, > but as of this moment I think this method is not a valid option for > authenticating > a client according to the draft-ietf-oauth-v2-1. > > On the other hand, authenticating the client through the BFF > seems conforming to the spec., but in the case when the access token is > used > in the browser in fact, I am afraid that it can be regarded as > some kind of "deception" of the AS. > > It seems the frontend SPA is not the easiest way to go with oauth... > > Stoycho. > > On Sun, 14 Feb 2021 at 17:35, Warren Parad <wpa...@rhosys.ch> wrote: > >> redirect_uri and use PKCE via the code verifier. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress <https://authress.io>. >> >> >> On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov < >> stoycho.slept...@gmail.com> wrote: >> >>> 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
