* What is the frontend developer doing any different in the new hypothetical world than they would be, right now they are including an SDK and writing one line of code on login redirect/silent auth and one line of code for PKCE+code validation. If a service client needs to be authorized there would be a third line of code to call the backend.
As mentioned, the client code might not look very different- although in the TMI-BFF model the JS code might be even more succinct (given that the sign in parts are handled by the backend, they might simply be decorated routes on the middleware- no need for the JS to make those calls directly, just to hit the routes) and the SDK far more lightweight. The difference might be that if your authorization server does not support refresh token rotation or sender constraining RTs, with code+PKCE you might not be able to obtain the same functionality as TMI-BFF given that you might not have a way of renewing short lived tokens without full redirects (see discussion on ITP). That is a temporary situation, hopefully eventually all AS vendors will support rotation and/or sender constraint, but it is an example of how the proposal does have advantages. * These three lines still need to be present irrespective of whether you use an AS-proxy TMI-BFF or the AS directly. See above. That’s not necessarily the case, and what the client code looks like isn’t what TMI-BFF is trying to address anyway. * Except now we are encouraging every app to write a BFF and integrate their front channel with it. That is not the case. The scope of this proposal remains limited to apps that already have a backend. * Additionally, we aren't requiring less capabilities from the spec, we are just also requiring additional ones for a BFF. If there are capabilities this lets us drop from OAuth could you explain which ones those are, because since an AS can't know whether "customers" are going to want to use a BFF or not, it will still have to implement all the necessary AS features that already exist (and the new ones that don't). I don't see how this affords an AS any additional freedom. Once again, this proposal is not meant to lighten the AS burden, but to make the life of developers easier. I already mentioned the rotation/sender constraint capabilities that code+PKCE require for RTs to be used in a user agent, and the fact that various important AS on the market today do not offer that capability. There might be others: for example, until recently various important AS did not support CORS on their metadata and token endpoints, making the code+PKCE in the user agent impossible. My hope and assumption is that those are all temporary situations, and TMI-BFF goal is NOT to dispense AS developers from implementing those features. But those are concrete examples of cases in which TODAY an app developer (whose app has a backend) took a dependency on one AS without those features might be able to do more things in their app when using TMI-BFF than with JS code that relies on those AS capabilities to function. From: Warren Parad <wpa...@rhosys.ch> Date: Sunday, February 14, 2021 at 11:57 To: Vittorio Bertocci <vittorio.berto...@auth0.com> Cc: Stoycho Sleptsov <stoycho.slept...@gmail.com>, Neil Madden <neil.mad...@forgerock.com>, oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) but it does make things simpler for the frontend developer and requires less advanced capabilities in the AS. I guess I'm still getting lost on this point, which seems not yet justified for me. What is the frontend developer doing any different in the new hypothetical world than they would be, right now they are including an SDK and writing one line of code on login redirect/silent auth and one line of code for PKCE+code validation. If a service client needs to be authorized there would be a third line of code to call the backend. These three lines still need to be present irrespective of whether you use an AS-proxy TMI-BFF or the AS directly. Except now we are encouraging every app to write a BFF and integrate their front channel with it. Additionally, we aren't requiring less capabilities from the spec, we are just also requiring additional ones for a BFF. If there are capabilities this lets us drop from OAuth could you explain which ones those are, because since an AS can't know whether "customers" are going to want to use a BFF or not, it will still have to implement all the necessary AS features that already exist (and the new ones that don't). I don't see how this affords an AS any additional freedom. [Image removed by sender.] Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress<https://authress.io>. On Sun, Feb 14, 2021 at 8:39 PM Vittorio Bertocci <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>> wrote: In the TMI-BFF topology, the backend and frontend developer are the same person. The operations TMI-BFF describes are the functional equivalent of what the JS code of one SPA app using a code+PKCE SDK would do when retrieving previously obtaining tokens from the store in order to perform an API call. Whereas such an app would make that call in memory (and result in the same operations described here, either use a previously saved access token matching the requirements of the API call, or use artifacts like RTs to request a new access token matching the request) in TMI-BFF al the logic and persistence layer are in the backend, hence that query becomes a request to the backend instead of a local function call. The advantages have been described in other branches of this thread, but TL;DR- a lot of the token requesting work can be performed more reliably (eg less things can go wrong) from a confidential client and it’s easier for SDK developers to package it (see existing middlewares vs JS SDKs). Note that for the app developer this might still look like the same flow, asking a JS SDK to get the token the app needs to call an API, but the JS SDK would be dramatically simpler than the one performing code+PKCE in the user agent and entail communication between frontend a backend, hence the need to define how that communication happens if we want developers to be able to mix and match frontend and backend dev stacks. Again, this does not necessarily add security to the code+PKCE in the user agent model (which remains the only game in town for backendless SPAs), but it does make things simpler for the frontend developer and requires less advanced capabilities in the AS. From: Warren Parad <wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>> Date: Sunday, February 14, 2021 at 09:45 To: Stoycho Sleptsov <stoycho.slept...@gmail.com<mailto:stoycho.slept...@gmail.com>> Cc: Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>>, Vittorio Bertocci <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>>, oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) 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? Error! Filename not specified. 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<mailto: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<mailto:wpa...@rhosys.ch>> wrote: redirect_uri and use PKCE via the code verifier. Error! Filename not specified. 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<mailto: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<mailto: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<mailto: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<mailto: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
