Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Thank you Philippe for your comments! Some considerations: * It also aims to avoid the need for a reverse proxy-based BFF, but comes up short compared to such a BFF. That isn’t a goal. If the developer can use a reverse proxy, they should definitely go for it. Not getting tokens in the user

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

A couple of notes from my end: Developers building an application that consists of a frontend, a backend, and APIs indeed often struggle with identifying the correct client, especially with the combination of OAuth 2.0 and OIDC. Having a standardized way of handling such cases is definitely use

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

* Draft [..] essentially suggests that every app needs to run a BFF to do user token generation because an AS is no longer afforded the capability for some reason I believe this might be the crux of the problem, my impression is that you are attributing to the draft a way larger scope than i

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

*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 the

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

> > To restate, the TMI-BFF proposal is not trying to fix any of that... it’s > definitely not a top level driver. Great, then we are back to: what is the top level driver. Because, while I appreciate the circumstances around ITP2.1~ as I fully understand how identity providers like Auth0 are usin

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Thanks! I expect the frontend (as in JS code) not to kick in until the initial authorization has been perfomed. Breaking it down as a classic possible flow: - User navigates to the app page, clicks "sign in" - The backend redirects the user to the AS to perform a code grant (for the sake of argu

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Let me rewind a bit here. This was never presented as driving use case. * Neil suggested that the backend could simply give short lived JTWs for the frontent to call API. * I clarified that this would not be viable in the general case and provided an example scenario where backend issue

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 b

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi Vittorio, thanks for the explanation. Do you assume the frontend passes the code or initial refresh token to the backend using an application specific mechanism? Why isn’t this part of the bff-token request? best regards, Torsten. > Am 14.02.2021 um 20:19 schrieb Vittorio Bertocci > : > >

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

That only applies to third party cookies, it shouldn't affect third-party iframes as far as I'm aware. So unless we expect those to break, we probably shouldn't include that as a driving use case. Is there another measure that would be relevant here? Warren Parad Founder, CTO Secure your user dat

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi Torsten, thanks for looking into this! The idea is that the application backend performed all the interactive token acquisition steps before TMI-BFF come into play. Imagine that a regular web app performs an authorization code grant, requesting access token and refresh token in the process (an

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

ITP, for example From: Warren Parad Date: Sunday, February 14, 2021 at 04:54 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Can you expand on what silent authentication and session token s

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Within the spec “client authentication” refers to explicit authentication of the client using credentials. But you said initially that you wanted this to “determine if it is a first-party app, for example”. You can determine this based on the redirect_uri and the fact that only the legitimate cl

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 t

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

redirect_uri and use PKCE via the code verifier. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov wrote: > Thanks a lot for your answer Neil, > > as I am no

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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 ow

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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 (se

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi, I’m trying to understand your proposal. Section 1.2, bullet (B) states (B) If the backend does not already have a suitable access token obtained in previous flows and cached, it requests to the authorization server a new access token with the required characteristics, usin

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

If I understood correctly, PKCE try to guarantee that the app which requests the access token in exchange for authorization code is the same as the application which initiated the authorization request, but it cannot help to guarantee which app exactly that is (as per section 2.3 of the draft-ietf-

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Why doesn't PKCE help for authentication? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 2:48 PM Stoycho Sleptsov wrote: > I would like to add my reasons about the "Why are develop

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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 im

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

> > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measures > make it problematic. Which new browser measures? Warren Parad Founder, CTO Secure your user data and complete your authorization architect

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

One thing I should add here, and then I’ll head to bed given that it’s almost 5am here 😊- I am fully behind code+PKCE. Auth0 has been supporting code+PKCE in its JS SPA SDKs, including refresh token rotation support, since early last year. I stress this so that no one thinks this an attempt to ge

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Correct, the access token ends up in the JavaScript – the outcome is the same as code+PKCE, the access token end up in the user agent. The main difference is that some of the functionality is now outsourced to the backend but the calls to the RS still take place from the user agent. From: Domin

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

* For UI related functionality, i.e. document selection, user profile display/changes, contact updates, etc... You should be able to execute the client side silent authentication using the provided session token from the Azure AD AS, without needing to make any RO api calls nor user redirect

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi Warren, thanks for the thoughtful comments. Inline. * . It introduces a pseudo AS-like proxy which now has all the requirements of an AS and more. While AS SDKs provide easy ways for client UIs to effectively deal with communication via the AS, there's no way for the AS to provide stand

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

> > My biggest concern with browser-based applications is that the JavaScript > / browser has access to the access token (don’t care if it is in-memory or > local storage) - but this exactly seems to happen in D. Unless the AS passes the token back in a HttpOnly cookie (which Oauth doesn't technic

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi, Just making sure I understand - in your protocol flow diagram step D it looks like that the BFF is returning the access token to the front-end. Is that correct? My biggest concern with browser-based applications is that the JavaScript / browser has access to the access token (don’t care if it

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

> > For the trusted part, see above. For the short lived JWTs, that’s not > really an option. The most generic scenario addressed here is for APIs that > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we’re talking about a SPA applicatio

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Hi Neil, Thanks for the prompt comments! * Re: GET vs POST, personally I’d be fine with restricting to POST. * Re: RO-AS, interaction- perhaps it is not very clear from the text at the moment (first draft), but that is assumed that the RO went thru whatever interactive steps are necessa

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Thanks Stoycho for your comment! The TMI-BFF assumes that the interactive part of the flow (code grant for giving consent and getting access+refresh tokens, and anything necessary for establishing the session) occurs beforehand. It is not described in the spec itself, but it is expected that suc

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

I also flat out reject the premise of this draft. It introduces a pseudo AS-like proxy which now has all the requirements of an AS and more. While AS SDKs provide easy ways for client UIs to effectively deal with communication via the AS, there's no way for the AS to provide standard AS specific se

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

I have a lot of security concerns about this draft. The draft alludes to security issues associated with handling access tokens in the frontend but never really spells them out. From the Security Considerations it seems that the primary concern is with theft of access tokens from local storage