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

Makes sense, thanks. > On 18 Mar 2021, at 22:55, Brian Campbell wrote: > >  > Thanks Neil. I'll look at incorporating that guidance. Although I think > referencing might be more appropriate than incorporating directly. > >> On Mon, Mar 15, 2021 at 3:44 AM Neil Madden >> wrote: >> There is

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

Thanks Neil. I'll look at incorporating that guidance. Although I think referencing might be more appropriate than incorporating directly. On Mon, Mar 15, 2021 at 3:44 AM Neil Madden wrote: > There is now a draft from the W3C explicitly addressing Spectre and its > impacts on web security. I thi

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

There is now a draft from the W3C explicitly addressing Spectre and its impacts on web security. I think we should aim to incorporate the guidance for “dynamic subresources” [1], and in particular the first item in the list, which is recommendations for "Application-internal resources (private A

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

Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that y

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

I was mentioning it primarily as another example of the assumption that GET requests are safe. However, the draft rfc6265bis [1] does seem concerned about this, and mentions as a possible attack vector. This would again potentially pull the access token into the renderer’s memory space (until

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

Thanks Neil, Appreciate the insight and recommendations. I think we can incorporate that, more or less, into the next revision. One point to dig into just a bit more, you said that 'SameSite has a "GET-out clause" in the form of “lax”'. As I understand it, such a cookie would still only be sent on

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

> On 18 Feb 2021, at 12:25, Philippe De Ryck > wrote: > >> On 18 Feb 2021, at 13:08, Neil Madden wrote: >> >> Thanks for following up, Brian. Responses below. >> >>> On 17 Feb 2021, at 22:48, Brian Campbell wrote: >>> >>> Always appreciate (and often learn from) your insights, Neil. I'd li

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

> On 18 Feb 2021, at 13:08, Neil Madden wrote: > > Thanks for following up, Brian. Responses below. > >> On 17 Feb 2021, at 22:48, Brian Campbell > > wrote: >> >> Always appreciate (and often learn from) your insights, Neil. I'd like to >> dig into the CSRF

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

Thanks for following up, Brian. Responses below. > On 17 Feb 2021, at 22:48, Brian Campbell wrote: > > Always appreciate (and often learn from) your insights, Neil. I'd like to dig > into the CSRF thing a bit more though to understand better and hopefully do > the right thing in the draft. >

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

at also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > tors...@lodderstedt.net> > *Cc: *Vittorio Bertocc

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

Always appreciate (and often learn from) your insights, Neil. I'd like to dig into the CSRF thing a bit more though to understand better and hopefully do the right thing in the draft. It seems to me that a GET at the bff-token endpoint is "safe" in that it's effectively just a read. There could be

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

’t appear to be trivial- and there might be some >>>> considerations we consider obvious (eg scope escalation) that might not be >>>> super clear otherwise. >>>> >>>> In terms of the guidance, just to make sure I get the scope r

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

>> your customers? >> >> >> >> *From: *Dominick Baier >> *Date: *Wednesday, February 17, 2021 at 00:27 >> *To: *Brian Campbell , Torsten Lodderstedt < >> tors...@lodderstedt.net> >> *Cc: *Vittorio Bertocci , "oauth@ietf.org" < >&g

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

right- that > means that also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > tors...@lodderstedt.net> >

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

ke sure I get the scope right- that > means that also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > tors.

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

< oauth@ietf.org> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn’t that be just an extension to the “OAuth for web apps B

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

Thanks Vittorio and Brian for starting this work: I have deployed this pattern in the field on a number occasions, at security and tech savvy organizations, on their request. I'd describe it as a regular OAuth 2.0 web client with the addition of a well known endpoint meant for in-browser (counterpa

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

[OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn’t that be just an extension to the “OAuth for web apps BCP?”. All I can add here is - this approach woul

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

Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn’t that be just an extension to the “OAuth for web apps BCP?”. All I can add here is - this approach would not work for any of our customer. Because their real motivation is to implemen

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

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > We did attempt to capture the assumptions in the draft but clearly could have done a better job with it :)

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

Thank you again for the explanation. I think your assumption about the overall flow should be described in the draft. As I understand it now the core contribution of your proposal is to move refresh token management from frontend to backend. Is that correct? > Am 14.02.2021 um 21:35 schrie

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

Thank you for the comprehensive answer, Neil. Initially I said that "I need the client app. to be authenticated at the AS", and I meant authenticated as by the spec (explicit authentication). It seems that the reason which I gave as an example to explain why would I need that (to determine if it i

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

Yes, I’ve argued against this distinction for DPoP too. Since the first days of HttpOnly attackers learnt to proxy requests through the browser (as you know of course). This is not only to bypass the restrictions but it’s also just much better for the attacker because it hides their traffic and

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

> > On 15 Feb 2021, at 11:50, Neil Madden wrote: > >> On 15 Feb 2021, at 10:26, Philippe De Ryck >> wrote: >> >>> On 15 Feb 2021, at 11:14, Neil Madden >> > wrote: >>> On 15 Feb 2021, at 08:32, Philippe De Ryck >>>

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

Totally agree. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Mon, Feb 15, 2021 at 11:51 AM Neil Madden wrote: > > > On 15 Feb 2021, at 10:26, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> wrote: > >

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

> On 15 Feb 2021, at 10:26, Philippe De Ryck > wrote: > >  > >>> On 15 Feb 2021, at 11:14, Neil Madden wrote: >>> On 15 Feb 2021, at 08:32, Philippe De Ryck wrote: >>> [...] >>> >>> Compared to using a worker for handling RTs, I believe the TMI-BFF only >>> adds a singl

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

> On 15 Feb 2021, at 11:14, Neil Madden wrote: > >> On 15 Feb 2021, at 08:32, Philippe De Ryck >> wrote: >> >> [...] >> >> Compared to using a worker for handling RTs, I believe the TMI-BFF only adds >> a single security benefit: an attacker is no longer able to run a silent >> flow to obt

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

> On 15 Feb 2021, at 08:32, Philippe De Ryck > wrote: > > [...] > > Compared to using a worker for handling RTs, I believe the TMI-BFF only adds > a single security benefit: an attacker is no longer able to run a silent flow > to obtain a fresh set of tokens (since the client is now a confi

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

adds a single security benefit: an attacker is no longer able to run a silent flow to obtain a fresh set of tokens (since the client is now a confidential client). Hope this helps Philippe > > From: Philippe De Ryck > Date: Sunday, February 14, 2021 at 22:45 > To: Vittorio Bertocci &

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

De Ryck Date: Sunday, February 14, 2021 at 22:45 To: Vittorio Bertocci Cc: Warren Parad , "oauth@ietf.org" Subject: 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

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

, February 14, 2021 at 12:59 > To: Vittorio Bertocci <mailto:vittorio.berto...@auth0.com>> > Cc: Neil Madden <mailto:neil.mad...@forgerock.com>>, "oauth@ietf.org <mailto:oauth@ietf.org>" > mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] Tok

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

. From: Warren Parad Date: Sunday, February 14, 2021 at 12:59 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: 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 th

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

[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 fronte

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

uff happening in the user agent means less opportunities for > similar changes to impact the flows, but it’s definitely not a top level > driver. > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 11:41 > *To: *Vittorio Bertocci > *Cc: *Neil Madden ,

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)

level driver. From: Warren Parad Date: Sunday, February 14, 2021 at 11:41 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) That only applies to third party cookies, it shouldn'

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

less > advanced capabilities in the AS. > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 09:45 > *To: *Stoycho Sleptsov > *Cc: *Neil Madden , Vittorio Bertocci < > vittorio.berto...@auth0.com>, oauth > *Subject: *Re: [OAUTH-WG] Token Medi

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)

o: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > 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 stands for &g

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

Cc: Neil Madden , Vittorio Bertocci , oauth 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

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 ses

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)

nario. > > > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 03:48 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend >

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

that risk drifting into insecure waters without it. From: Vittorio Bertocci Date: Sunday, February 14, 2021 at 04:27 To: Warren Parad , Neil Madden Cc: oauth Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hi Warren, thanks for the thoughtful

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

: Dominick Baier Date: Sunday, February 14, 2021 at 04:06 To: Vittorio Bertocci , Brian Campbell , "oauth@ietf.org" Subject: 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 l

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

t;mailto:oauth@ietf.org>" mailto:oauth@ietf.org>> Subject: 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 fro

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

orio Bertocci , oauth Subject: 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

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)

ndpoint that is guaranteed to initiate > a sign in flow (hence inject all the necessary nonces etc). We didn’t add > it upfront and left it as exercise for the reader mostly because it’s not > easy to model properly and before opening that work front we wanted to see > how the idea was

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

behalf of Neil Madden Date: Sunday, February 14, 2021 at 00:17 To: Vittorio Bertocci Cc: "oauth@ietf.org" Subject: 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 secur

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

such flow (or extension grant with the same characteristics) happened. HTH! V. From: OAuth on behalf of Stoycho Sleptsov Date: Saturday, February 13, 2021 at 19:39 To: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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

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

Hello Mr. Bertocci, I am a novice yet at APIs and OAuth, but nevertheless am entrusted by the executives of our organisation to expose some of the capabilities of our system through APIs. For that I have set out to implement an OAuth server (based on the 2.1 draft), which is basically functional n

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

Dear all, Brian and yours truly are proposing a new specification that shows how the user agent frontend of a web app can delegate token acquisition and persistence to its backend, and request such tokens when needed for direct access of protected resources from the frontend code. The pattern i