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

[Vittorio Bertocci]

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 agent at all is the safest 
option. TMI-BFF is for the cases where it is not a viable option- thru the 
threads I mentioned some of those cases.


  *   Section 6.1 states not to use localStorage (I assume because of malicious 
JS code),…
We might have been naïve there- a common discussion point even when considering 
code+PKCE is that local storage is somehow vulnerable to more exploits than 
memory.
If there are attacks that only work with storage but not with memory, this 
would be an incremental improvement. If every attack that can access the 
storage can also access memory, then I agree it’s a moot point- but then the 
current public discourse needs a severe reset given that the two options are 
presented as having very different security properties.



  *   you lose the ability to use sender constrained tokens, which a proxy BFF 
would be able to do
Absolutely. If the reverse proxy is an option, the security improves for sure. 
TMI-BFF is meant to help when it is not an option.



  *   Keeping refresh tokens on the backend is good, but not necessarily better 
than keeping them in a web worker, as Auth0’s JS SDK
A web worker is definitely good practice, but it’s still on the local machine. 
One might argue it’s enough security for the scenario, but not the same as not 
having the tokens available at all in the local box. But as you say, the thrust 
behind TMI-BFF is more about dev experience- I’d be happy with equivalent 
security with code+PKCE+RTs

From: Philippe 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 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 useful.

That said, the current spec is a bit all over the place. Vittorio stated here 
that the main goal is to make it easier for developers, but the spec makes 
quite a bit of (vague) security statements. It also aims to avoid the need for 
a reverse proxy-based BFF, but comes up short compared to such a BFF.

A few detailed security notes:

1) Section 6.1 states not to use localStorage (I assume because of malicious JS 
code), which makes no sense. If malicious code is running in the frontend, it 
can simply call the bff-token endpoint and grab the token from there. Other 
attacks typically also allow to steal tokens from memory (e.g., prototype 
pollution attacks as I discuss here: 
https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html).

2) The use of confidential clients is a big plus, but since the access token is 
used in the frontend, you lose the ability to use sender constrained tokens, 
which a proxy BFF would be able to do. A proxy-based BFF can also limit the API 
endpoints it exposes to a specific frontend and can apply traffic analysis to 
detect malicious behavior from a compromised frontend.

3) Keeping refresh tokens on the backend is good, but not necessarily better 
than keeping them in a web worker, as Auth0’s JS SDK (and presumably others, 
haven’t checked) does by default.

Overall, my recommendation is to focus on the specific use case of handling 
tokens in a “frontend with backend” application type, and forget about trying 
to also solve security issues in frontends caused by malicious JS.

Philippe


—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/


On 14 Feb 2021, at 22:31, Vittorio Bertocci 
mailto:vittorio.bertocci=40auth0@dmarc.ietf.org>>
 wrote:


  *   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 it is intended to have. The 
draft makes no such suggestion. The draft says nothing about AS losing 
capabilities. The draft is not trying to solve an AS problem. And above all, 
the draft does not target every app.

The draft is an optimization aimed at a very specific, albeit very common, 
application topology where there is a frontend and a backend, and the developer 
wants to perform API calls from the frontend directly to the RS. This is only a 
specific topology, and the proposal is scoped down to that. All other 
topologies are unaffected. Also, the draft isn’t pushing this topology as the 
preferred one. It’s best 

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

[Philippe De Ryck]

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 useful. 

That said, the current spec is a bit all over the place. Vittorio stated here 
that the main goal is to make it easier for developers, but the spec makes 
quite a bit of (vague) security statements. It also aims to avoid the need for 
a reverse proxy-based BFF, but comes up short compared to such a BFF. 

A few detailed security notes:

1) Section 6.1 states not to use localStorage (I assume because of malicious JS 
code), which makes no sense. If malicious code is running in the frontend, it 
can simply call the bff-token endpoint and grab the token from there. Other 
attacks typically also allow to steal tokens from memory (e.g., prototype 
pollution attacks as I discuss here: 
https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html 
). 

2) The use of confidential clients is a big plus, but since the access token is 
used in the frontend, you lose the ability to use sender constrained tokens, 
which a proxy BFF would be able to do. A proxy-based BFF can also limit the API 
endpoints it exposes to a specific frontend and can apply traffic analysis to 
detect malicious behavior from a compromised frontend.

3) Keeping refresh tokens on the backend is good, but not necessarily better 
than keeping them in a web worker, as Auth0’s JS SDK (and presumably others, 
haven’t checked) does by default. 

Overall, my recommendation is to focus on the specific use case of handling 
tokens in a “frontend with backend” application type, and forget about trying 
to also solve security issues in frontends caused by malicious JS.

Philippe


—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/


> On 14 Feb 2021, at 22:31, Vittorio Bertocci 
>  wrote:
> 
> 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 it is intended to have. 
> The draft makes no such suggestion. The draft says nothing about AS losing 
> capabilities. The draft is not trying to solve an AS problem. And above all, 
> the draft does not target every app. 
>  
> The draft is an optimization aimed at a very specific, albeit very common, 
> application topology where there is a frontend and a backend, and the 
> developer wants to perform API calls from the frontend directly to the RS. 
> This is only a specific topology, and the proposal is scoped down to that. 
> All other topologies are unaffected. Also, the draft isn’t pushing this 
> topology as the preferred one. It’s best to keep tokens out of the frontend 
> altogether. But if the developer is adamant in performing API calls direct 
> from their JS, and if they already have a backend, and only in that case, the 
> current proposal has less moving parts and less requirements than code+PKCE .
>  
> Code+PKCE already has the expressive power to handle the scenario described 
> here, and is applicable to a wider range of scenarios. The main point the 
> draft brings to the table is the ability for a frontend to delegate to a 
> backend a lot of logic that in the code+PKCE case executes in an environment 
> that is naturally more constrained and prone to attacks than a backend. That 
> doesn’t mean developers whose app has a backend should automatically choose 
> the new model over code+PKCE, more that the model discussed here might be 
> viable and require less capabilities/moving parts to achieve the same 
> expressive power, especially if the SDKs used in the solution have a standard 
> way to handle it. That is far from every app, but it is a situation I 
> encountered in the wild often enough to prompt the discussion with Brian and 
> the draft.
>  
> As a side note, the initial reactions of practitioners have been very 
> positive. I am really hoping the discussion will lead to identifying and 
> weeding out security issues, or land on security flaws in the model so grave 
> that they can be properly used to discourage its use. No matter what way it 
> will go, I am very glad the discussion is taking place.
>  
> From: Warren Parad  >
> Date: Sunday, February 14, 2021 at 12:59
> To: Vittorio Bertocci  >
> Cc: Neil Madden  >, "oauth@ietf.org " 
> mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For 
> Frontend (TMI BFF)
>  
> To restate, the TMI-BFF 

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

[Vittorio Bertocci]

  *   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 it is intended to have. The 
draft makes no such suggestion. The draft says nothing about AS losing 
capabilities. The draft is not trying to solve an AS problem. And above all, 
the draft does not target every app.

The draft is an optimization aimed at a very specific, albeit very common, 
application topology where there is a frontend and a backend, and the developer 
wants to perform API calls from the frontend directly to the RS. This is only a 
specific topology, and the proposal is scoped down to that. All other 
topologies are unaffected. Also, the draft isn’t pushing this topology as the 
preferred one. It’s best to keep tokens out of the frontend altogether. But if 
the developer is adamant in performing API calls direct from their JS, and if 
they already have a backend, and only in that case, the current proposal has 
less moving parts and less requirements than code+PKCE .

Code+PKCE already has the expressive power to handle the scenario described 
here, and is applicable to a wider range of scenarios. The main point the draft 
brings to the table is the ability for a frontend to delegate to a backend a 
lot of logic that in the code+PKCE case executes in an environment that is 
naturally more constrained and prone to attacks than a backend. That doesn’t 
mean developers whose app has a backend should automatically choose the new 
model over code+PKCE, more that the model discussed here might be viable and 
require less capabilities/moving parts to achieve the same expressive power, 
especially if the SDKs used in the solution have a standard way to handle it. 
That is far from every app, but it is a situation I encountered in the wild 
often enough to prompt the discussion with Brian and the draft.

As a side note, the initial reactions of practitioners have been very positive. 
I am really hoping the discussion will lead to identifying and weeding out 
security issues, or land on security flaws in the model so grave that they can 
be properly used to discourage its use. No matter what way it will go, I am 
very glad the discussion is taking place.

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 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 using iframes and thirdparty cookies, this problem 
vanishes with the use of first-party domains. So let's skip the digression and 
assume we aren't solving ITP future related issues.

The real problem I have with the draft is that it 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. If we pull in expecting to 
solve ITP related issues then I think that justification is in play and we can 
work together to come up with a solution, rather than starting with the current 
deleterious prevalent pattern on the internet (which honestly is the most 
ridiculous paradigm I have seen). If we don't assume ITP is an issue, then I 
fail to see the core problem that existing AS have (as you pointed out 
code+PKCE already works) without the front channel or back channel needing 
really to make any additional changes.

I assume there is a flaw in my reasoning somewhere, so please help me find it.

- Warren


[Image removed by sender.]

Warren Parad

Founder, CTO


On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
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 issued short lived tokens would not 
have worked
  *   You commented that the frontend can obtain AS tokens from JS and 
mentioned silent authentication. I clarified (or tried to) that this offshoot 
of the discussion wasn’t to say that there is no viable way of doing the 
scenario already, and by the way using an iFrame to do silent authentication is 
now problematic. At this point we are no longer discussing TMI-BFF, but current 
affairs in the authentication world. The fact that we are proposing TMI-BFF and 
the fact that silent authentication is less and less viable are independent 
facts, the former isn’t meant to be a 

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

[Vittorio Bertocci]

  *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 
Date: Sunday, February 14, 2021 at 11:57
To: Vittorio Bertocci 
Cc: Stoycho Sleptsov , Neil Madden 
, oauth 
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.


On Sun, Feb 14, 2021 at 8:39 PM Vittorio Bertocci 
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 

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

[Warren Parad]

>
> 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 using iframes and thirdparty cookies,
this problem vanishes with the use of first-party domains. So let's skip
the digression and assume we aren't solving ITP future related issues.

The real problem I have with the draft is that it 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. If we pull in expecting
to solve ITP related issues then I think that justification is in play and
we can work together to come up with a solution, rather than starting with
the current deleterious prevalent pattern on the internet (which honestly
is the most ridiculous paradigm I have seen). If we don't assume ITP is an
issue, then I fail to see the core problem that existing AS have (as you
pointed out code+PKCE already works) without the front channel or back
channel needing really to make any additional changes.

I assume there is a flaw in my reasoning somewhere, so please help me find
it.

- Warren

Warren Parad

Founder, CTO


On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci  wrote:

> 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 issued short lived tokens would
>not have worked
>- You commented that the frontend can obtain AS tokens from JS and
>mentioned silent authentication. I clarified (or tried to) that this
>offshoot of the discussion wasn’t to say that there is no viable way of
>doing the scenario already, and by the way using an iFrame to do silent
>authentication is now problematic. At this point we are no longer
>discussing TMI-BFF, but current affairs in the authentication world. The
>fact that we are proposing TMI-BFF and the fact that silent authentication
>is less and less viable are independent facts, the former isn’t meant to be
>a solution for the latter (it’s already addressed by using RTs in 
> coke+PKCE)
>
>
>
> That clarified. Not only we expect ITP to affect silent authentication, it
> has been affected for the past year and that has been one of the primary
> business drivers for the rapid adoption of code+PKCE+RTs in the user agent,
> as customers with pure SPAs found themselves unable to renew tokens without
> prompting as their access to cookies in flows driven by iframes became less
> and less reliable.
>
> When ITP was introduced we put many companies together to try to get Apple
> to change it (you can find the doc in
> https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7sKsaiU/edit#heading=h.p3nvp6xmxvzf)
> but they didn’t bulge and ultimately the introduction of RTs in user agent
> code (albeit with extra restrictions, the one I mentioned not everyone is
> following) made the problem manageable. We have an initiative cross working
> groups (IETF, OIDC etc)for working with browser vendors to try containing
> similar regressions in the future. For a summary of similar problems see
> https://identiverse.gallery.video/detail/video/6184443037001/browser-features-vs-identity-protocols.
>
>
>
>
> To restate, the TMI-BFF proposal is not trying to fix any of that, nor per
> the above some of it need fixing. The only indirect connection might be
> that less stuff 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 , "oauth@ietf.org" <
> 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'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?
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
>
>
>
> On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> ITP, for example
>
>
>
> *From: *Warren Parad 
> *Date: *Sunday, February 14, 2021 at 04:54
> *To: *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 

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

[Vittorio Bertocci]

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 argument let's also say they ask for an IDtoken as well tho it isn’t 
strictly necessary), with the purpose of gathering consent for the scopes 
required. No frontend code involved. 
- The code grant concludes successfully, the backend now has a session with the 
user agent and an AT, RT stored on the server side
- --> here TMI-BFF begins. Whenever the frontend needs a token to call an API, 
they use TMI-BFF to ask for that token to the backend
- if the backend can return the requested token, via stored AT or by using the 
RT, it does it
- if the backend cannot get the requested token with what it already has 
without suer interaction, it fails
--> here there's where TMI-BFF ends- it's up to the backend to decide how to 
meet the new requirements, eg by triggering another authorization code grant 
for new scopes. The frontend is not involved apart from perhaps offering 
affordances to the end upper to start such process

TMI-BFF does not include the actual authorization requests mostly for 
simplicity. We don’t really know how the app is structured nor the reasons for 
which a backend might be unable to get the requested token. The RT might be 
expired; or the current scopes might be insufficient; or the AS might decide 
that now issuing an AT with that scope might require a different authentication 
method; and many other reasons I can’t think of. If we were to provide a 
mechanism that includes in the error message indications on what the frontent 
should do to remediate the error, we might need to either scope down the 
scenarios or create a very flexible mechanism. I am not opposed, but before 
venturing into that we wanted to see what the reaction would be.  

On 2/14/21, 11:45, "Torsten Lodderstedt" 
 wrote:

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 
:
> 
> 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 (and often also 
setting its own session with the user agent in the process, if the AS is also 
their IdP via OIDC or similar, but that's not strictly necessary). Now the app 
backend has an access token and refresh token persisted on the server side.
> All TMI-BFF does is to describe how the backend can share those tokens 
with its fronted, either directly (if the persisted AT is still valid) or 
indirectly (if it has to use an RT to obtain a new AT before sending it back).
> The frontend provides resource and scope to select what token it needs, 
but the current idea is that the backend already obtained both consent and 
artifacts to obtain those tokens from the AS. And if it doesn't, at the moment 
we simply fail and expect the app developer to take the steps required to 
prompt the user with whatever is necessary for updating the backend with the 
right permissions, eg creating a new authorization request asking for a scope 
the frontend needs and that the user wasn't prompted to consent yet. At the 
moment TMI-BFF does not provide a mechanism for that prompt to occur, it just 
errors out saying "you've got to  update your authorization artifacts before 
the frontend can get the token w the scopes it needs".
> Another way to think about this: in TMI-BFF the frontend treats the 
backend is a tokens database. Indicating the resource and scopes is a query. If 
the backend can serve that query (with the ATs it saved, or by using the RTs it 
saved AND the grants the user already gave) it returns a token. If it doesn't, 
it fails the query. The frontend does not play a direct role into inserting in 
the DB more tokens. That is left to the backend, that can do so by initiating a 
new authorization grant, not described in TMI-BFF, that must conclude 
successfully for the frontend to be able to repeat its query and this time get 
the token they want out. Note that the backend might decide that it won’t try 
to get the token requested, or it might unable to do so (eg the user/app cannot 
meet some requirements as the AS is concerned), hence the request of it might 
at times be permanently denied. This last part is to say that providing in the 
error message details about the remediation might take more work than one 
realizes at first, and ultimately acting on the 

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

[Vittorio Bertocci]

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 issued short lived tokens would not 
have worked
  *   You commented that the frontend can obtain AS tokens from JS and 
mentioned silent authentication. I clarified (or tried to) that this offshoot 
of the discussion wasn’t to say that there is no viable way of doing the 
scenario already, and by the way using an iFrame to do silent authentication is 
now problematic. At this point we are no longer discussing TMI-BFF, but current 
affairs in the authentication world. The fact that we are proposing TMI-BFF and 
the fact that silent authentication is less and less viable are independent 
facts, the former isn’t meant to be a solution for the latter (it’s already 
addressed by using RTs in coke+PKCE)

That clarified. Not only we expect ITP to affect silent authentication, it has 
been affected for the past year and that has been one of the primary business 
drivers for the rapid adoption of code+PKCE+RTs in the user agent, as customers 
with pure SPAs found themselves unable to renew tokens without prompting as 
their access to cookies in flows driven by iframes became less and less 
reliable.
When ITP was introduced we put many companies together to try to get Apple to 
change it (you can find the doc in 
https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7sKsaiU/edit#heading=h.p3nvp6xmxvzf)
 but they didn’t bulge and ultimately the introduction of RTs in user agent 
code (albeit with extra restrictions, the one I mentioned not everyone is 
following) made the problem manageable. We have an initiative cross working 
groups (IETF, OIDC etc)for working with browser vendors to try containing 
similar regressions in the future. For a summary of similar problems see 
https://identiverse.gallery.video/detail/video/6184443037001/browser-features-vs-identity-protocols.

To restate, the TMI-BFF proposal is not trying to fix any of that, nor per the 
above some of it need fixing. The only indirect connection might be that less 
stuff 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 , "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'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?


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
ITP, for example

From: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Date: Sunday, February 14, 2021 at 04:54
To: Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>>
Cc: Neil Madden mailto:neil.mad...@forgerock.com>>, 
"oauth@ietf.org" mailto: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 here? 
If you are referring to the iframe scenario, the new browser measures make it 
problematic.
Which new browser measures?


Error! Filename not specified.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:

  *   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 redirects.
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. In code+PKCE you can use a refresh token, but see the other reply 
for how this proposal is an alternative to that in some situations. This answer 
was specifically on why having backend-issued tokens didn’t apply to this 
scenario.


From: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>>
Cc: Neil Madden mailto:neil.mad...@forgerock.com>>, 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Subject: 

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

[Warren Parad]

>
> 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.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 8:39 PM Vittorio Bertocci <
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 
> *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 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?
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
>
>
>
> 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 

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

[Torsten Lodderstedt]

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 
> :
> 
> 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 (and often also 
> setting its own session with the user agent in the process, if the AS is also 
> their IdP via OIDC or similar, but that's not strictly necessary). Now the 
> app backend has an access token and refresh token persisted on the server 
> side.
> All TMI-BFF does is to describe how the backend can share those tokens with 
> its fronted, either directly (if the persisted AT is still valid) or 
> indirectly (if it has to use an RT to obtain a new AT before sending it back).
> The frontend provides resource and scope to select what token it needs, but 
> the current idea is that the backend already obtained both consent and 
> artifacts to obtain those tokens from the AS. And if it doesn't, at the 
> moment we simply fail and expect the app developer to take the steps required 
> to prompt the user with whatever is necessary for updating the backend with 
> the right permissions, eg creating a new authorization request asking for a 
> scope the frontend needs and that the user wasn't prompted to consent yet. At 
> the moment TMI-BFF does not provide a mechanism for that prompt to occur, it 
> just errors out saying "you've got to  update your authorization artifacts 
> before the frontend can get the token w the scopes it needs".
> Another way to think about this: in TMI-BFF the frontend treats the backend 
> is a tokens database. Indicating the resource and scopes is a query. If the 
> backend can serve that query (with the ATs it saved, or by using the RTs it 
> saved AND the grants the user already gave) it returns a token. If it 
> doesn't, it fails the query. The frontend does not play a direct role into 
> inserting in the DB more tokens. That is left to the backend, that can do so 
> by initiating a new authorization grant, not described in TMI-BFF, that must 
> conclude successfully for the frontend to be able to repeat its query and 
> this time get the token they want out. Note that the backend might decide 
> that it won’t try to get the token requested, or it might unable to do so (eg 
> the user/app cannot meet some requirements as the AS is concerned), hence the 
> request of it might at times be permanently denied. This last part is to say 
> that providing in the error message details about the remediation might take 
> more work than one realizes at first, and ultimately acting on the error 
> situation to retrieve a new token is still up to the backend anyway, hence 
> providing elaborate machinery to inform the frontend beyond the error 
> situation might not be as effective as it might look at first glance. I am 
> totally open to it, just making sure we understand what it can buy us.  
> 
> On 2/14/21, 06:11, "Torsten Lodderstedt" 
>  wrote:
> 
>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, using any artifacts previousy obtained (eg
>  refresh token) and grants that will allow the authorization server
>  to issue the requested token without requiring user interaction.
> 
>Can you please explain how the authorization process works towards the AS, 
> especially in case of the authorisation code grant type. I would have 
> expected to frontend to pass an authorisation code to the bff-token request. 
> 
>But section 4.1. only defines the parameters „resource" and „scope" for 
> the bff-token endpoint. 
> 
>thanks,
>Torsten. 
> 
>> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci 
>> :
>> 
>> 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 is already in use, in proprietary form, by various modern 
>> development stacks, such as Next.JS. Variants of the pattern, often 
>> discussed under the catch-all term BFF (backend for frontend), have been 
>> often mentioned in this workgroup’s activity, but always left all 
>> implementation details to the reader.
>> We believe the pattern has merit, as corroborated 

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

[Warren Parad]

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 data and complete your authorization architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci  wrote:

> ITP, for example
>
>
>
> *From: *Warren Parad 
> *Date: *Sunday, February 14, 2021 at 04:54
> *To: *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
> here? If you are referring to the iframe scenario, the new browser measures
> make it problematic.
>
> Which new browser measures?
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
>
>
>
> On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>
>- 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
>redirects.
>
> 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. In code+PKCE you can use a refresh token, but see the
> other reply for how this proposal is an alternative to that in some
> situations. This answer was specifically on why having backend-issued
> tokens didn’t apply to this scenario.
>
>
>
>
>
> *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
> 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 application that
> signs in users using Azure AD, and needs to call Office and Azure APIs. The
> SPA backend cannot issue tokens for those APIs, it can only request them to
> the Azure AD AS.
>
>
>
> 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
> redirects. For RO responsibilities, you can present the user with a button
> "Grant RO access to Azure resources" button and the user will go through a
> permission scope elevation flow, again no reason to need a BFF here.
>
>
>
> We did consider adding something to that effect, an error message that can
> direct the frontend to perform the interactive portion necessary for this
> topology to work. It would be something similar to the IDP initiated login
> in OIDC, where the client offers an endpoint 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 received.
>
> It may make sense for the app to have an error message, or even better
> might be a 302 *Location header* depending on what you are doing. There
> is nothing here that is OAuth specific however (nor common), and then we
> should challenge the need to directly provide an RFC recommendation for
> handling this.
>
>
>
> *Error! Filename not specified.*
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
>
>
>
> On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> 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
> necessary to establish a session (eg sign in, assuming the AS is say an
> OIDC provider) and obtain beforehand the access token and refresh tokens
> that will be needed during the app activities taking place after  that. In
> concrete terms, imagine 

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

[Vittorio Bertocci]

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 
Date: Sunday, February 14, 2021 at 09:45
To: Stoycho Sleptsov 
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 
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?


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov 
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 
mailto:wpa...@rhosys.ch>> wrote:
redirect_uri and use PKCE via the code verifier.


[Image removed by sender.]

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 
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 
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, 

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

[Vittorio Bertocci]

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 (and often also setting its own 
session with the user agent in the process, if the AS is also their IdP via 
OIDC or similar, but that's not strictly necessary). Now the app backend has an 
access token and refresh token persisted on the server side.
All TMI-BFF does is to describe how the backend can share those tokens with its 
fronted, either directly (if the persisted AT is still valid) or indirectly (if 
it has to use an RT to obtain a new AT before sending it back).
The frontend provides resource and scope to select what token it needs, but the 
current idea is that the backend already obtained both consent and artifacts to 
obtain those tokens from the AS. And if it doesn't, at the moment we simply 
fail and expect the app developer to take the steps required to prompt the user 
with whatever is necessary for updating the backend with the right permissions, 
eg creating a new authorization request asking for a scope the frontend needs 
and that the user wasn't prompted to consent yet. At the moment TMI-BFF does 
not provide a mechanism for that prompt to occur, it just errors out saying 
"you've got to  update your authorization artifacts before the frontend can get 
the token w the scopes it needs".
Another way to think about this: in TMI-BFF the frontend treats the backend is 
a tokens database. Indicating the resource and scopes is a query. If the 
backend can serve that query (with the ATs it saved, or by using the RTs it 
saved AND the grants the user already gave) it returns a token. If it doesn't, 
it fails the query. The frontend does not play a direct role into inserting in 
the DB more tokens. That is left to the backend, that can do so by initiating a 
new authorization grant, not described in TMI-BFF, that must conclude 
successfully for the frontend to be able to repeat its query and this time get 
the token they want out. Note that the backend might decide that it won’t try 
to get the token requested, or it might unable to do so (eg the user/app cannot 
meet some requirements as the AS is concerned), hence the request of it might 
at times be permanently denied. This last part is to say that providing in the 
error message details about the remediation might take more work than one 
realizes at first, and ultimately acting on the error situation to retrieve a 
new token is still up to the backend anyway, hence providing elaborate 
machinery to inform the frontend beyond the error situation might not be as 
effective as it might look at first glance. I am totally open to it, just 
making sure we understand what it can buy us.  

On 2/14/21, 06:11, "Torsten Lodderstedt" 
 wrote:

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, using any artifacts previousy obtained (eg
  refresh token) and grants that will allow the authorization server
  to issue the requested token without requiring user interaction.

Can you please explain how the authorization process works towards the AS, 
especially in case of the authorisation code grant type. I would have expected 
to frontend to pass an authorisation code to the bff-token request. 

But section 4.1. only defines the parameters „resource" and „scope" for the 
bff-token endpoint. 

thanks,
Torsten. 

> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci 
:
> 
> 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 is already in use, in proprietary form, by various modern 
development stacks, such as Next.JS. Variants of the pattern, often discussed 
under the catch-all term BFF (backend for frontend), have been often mentioned 
in this workgroup’s activity, but always left all implementation details to the 
reader.
> We believe the pattern has merit, as corroborated by its growing 
adoption. By delegating access token acquisition to the backend, we avoid many 
of the often brittle moving parts (and implied attack surface) required to 
acquire access tokens from a user agent. The topology also relieves the 
frontend from the need of persisting tokens in local storage, a well known sore 
point of using OAuth directly in JavaScript, by relying on its backend 

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

[Vittorio Bertocci]

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 stands for here? 
If you are referring to the iframe scenario, the new browser measures make it 
problematic.
Which new browser measures?


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:

  *   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 redirects.
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. In code+PKCE you can use a refresh token, but see the other reply 
for how this proposal is an alternative to that in some situations. This answer 
was specifically on why having backend-issued tokens didn’t apply to this 
scenario.


From: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>>
Cc: Neil Madden mailto:neil.mad...@forgerock.com>>, 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Subject: 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 application that signs in users using 
Azure AD, and needs to call Office and Azure APIs. The SPA backend cannot issue 
tokens for those APIs, it can only request them to the Azure AD AS.

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 redirects. For 
RO responsibilities, you can present the user with a button "Grant RO access to 
Azure resources" button and the user will go through a permission scope 
elevation flow, again no reason to need a BFF here.

We did consider adding something to that effect, an error message that can 
direct the frontend to perform the interactive portion necessary for this 
topology to work. It would be something similar to the IDP initiated login in 
OIDC, where the client offers an endpoint 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 
received.
It may make sense for the app to have an error message, or even better might be 
a 302 Location header depending on what you are doing. There is nothing here 
that is OAuth specific however (nor common), and then we should challenge the 
need to directly provide an RFC recommendation for handling this.


Error! Filename not specified.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
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 necessary 
to establish a session (eg sign in, assuming the AS is say an OIDC provider) 
and obtain beforehand the access token and refresh tokens that will be needed 
during the app activities taking place after  that. In concrete terms, imagine 
that the backend performs an authorization code grant requesting an IDtoken, 
access token and refresh token BEFORE the activities described in TMI-BFF take 
place.
The current language trying to express that is in 1.2:
As a prerequisite for the flow described below, the backend MUST have 
established a secure session with the user agent, so that all requests from 
that user agent toward the backend occur over HTTPS and carry a valid session 
artifact (such as a cookie) that the backend can validate. This document does 
not mandate any specific mechanism to 

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

[Neil Madden]

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 client can 
receive an authorization code at that redirect_uri (if its HTTPS, exact 
matching of URIs, etc). This is what I refer to as implicit authentication - 
the AS knows at the point of auth code exchange that only the legitimate client 
could have obtained that code. 

(This is not true for mobile clients using private-use URI schemes).

Note that for both public and confidential clients, the confirmation of the 
client identity happens after the user has gone through the authorization flow. 
PAR fixes this for confidential clients, but not public ones. So that is one 
reason to prefer a BFF pattern and a confidential client. 

Confidential clients also have an extra layer of defence in depth: they need a 
redirect_uri *and* client credentials. So that is another reason to use a 
confidential client and BFF. 

A backend server may also have a more reliable connection to the AS. So that 
may also be a good reason to use a BFF - eg to avoid having to reauthorize with 
the user because an auth code or refresh request timed out due to a flaky 
network connection. 

So there may be many good reasons to use a BFF pattern. But if you just want a 
reasonable assurance of client identity at the point of issuing tokens, then 
IMO a public client + PKCE is fine for many cases. 

— Neil

> On 14 Feb 2021, at 17:27, Stoycho Sleptsov  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  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.
>> 
>> 
>> On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov 
>>  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  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  
>>> > > 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 

-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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 .


On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov 
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  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 .
>>
>>
>> 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 
>>> 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 
>>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Stoycho Sleptsov]

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  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 .
>
>
> 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 
>> 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 
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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 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 
> 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 
> 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 
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Stoycho Sleptsov]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

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, using any artifacts previousy obtained (eg
  refresh token) and grants that will allow the authorization server
  to issue the requested token without requiring user interaction.

Can you please explain how the authorization process works towards the AS, 
especially in case of the authorisation code grant type. I would have expected 
to frontend to pass an authorisation code to the bff-token request. 

But section 4.1. only defines the parameters „resource" and „scope" for the 
bff-token endpoint. 

thanks,
Torsten. 

> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci 
> :
> 
> 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 is already in use, in proprietary form, by various modern 
> development stacks, such as Next.JS. Variants of the pattern, often discussed 
> under the catch-all term BFF (backend for frontend), have been often 
> mentioned in this workgroup’s activity, but always left all implementation 
> details to the reader.
> We believe the pattern has merit, as corroborated by its growing adoption. By 
> delegating access token acquisition to the backend, we avoid many of the 
> often brittle moving parts (and implied attack surface) required to acquire 
> access tokens from a user agent. The topology also relieves the frontend from 
> the need of persisting tokens in local storage, a well known sore point of 
> using OAuth directly in JavaScript, by relying on its backend storage and 
> session to preserve tokens.
> 
> Although the specification is very simple, providing explicit guidance on the 
> scenario offers many advantages.  
> - It makes it possible to create interoperable SDKs, where frontend dev 
> stacks (any JS flavor) can be mixed and matched with compliant backend stacks 
> (middlewares in node, java, ASP.NET, PHP etc)
> - It allows us to provide guidance on how to properly tackle the scenario and 
> warn implementers against security risks (scope escalations, using IDtokens 
> instead of access tokens, etc)
> - It allows us to discuss (and when appropriate, promote) this pattern as 
> part of the browser apps security guidance, and position the scenario where 
> frontend only calls API on its own backed (hence doesn’t need access tokens) 
> simply as a special case of this more general pattern
> - This approach makes mocking and testing apps very easy, possibly preventing 
> developers from weakening the security of their system (eg turning on ROPG 
> options)  or turning to risky practices like scraping
> 
> Needless to say, this specification doesn’t entirely eliminate the risks 
> inherent to direct use of access tokens from a browser. But reality is that 
> the pattern is in widespread use, and the circumstances leading to that (eg 
> developers on a particular project only work with frontend stacks; components 
> like reverse proxies might not always be viable; etc) aren’t going away any 
> time soon. By providing simple guidance on this pattern, we can simplify the 
> life of many developers while enshrining basic security hygiene in scenarios 
> that would have otherwise be left to their own device.
> 
> Looking forward for your feedback!
> 
> B  
> 
> On 2/12/21, 12:41, "internet-dra...@ietf.org"  
> wrote:
> 
> 
>A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
>has been successfully submitted by Vittorio Bertocci and posted to the
>IETF repository.
> 
>Name:  draft-bertocci-oauth2-tmi-bff
>Revision:  00
>Title: Token Mediating and session Information Backend For 
> Frontend
>Document date: 2021-02-12
>Group: Individual Submission
>Pages: 16
>URL:
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt=gmail-imap=161376759100=AOvVaw3Rb-S0l6cEv0ytjDxtYLAP
>Status: 
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/=gmail-imap=161376759100=AOvVaw3-qg5MDtY7kD1HpR5jR2QY
>Html:   
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html=gmail-imap=161376759100=AOvVaw05WK4GSEKcWjZzNhvb1p5d
>Htmlized:   
> https://www.google.com/url?q=https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00=gmail-imap=161376759100=AOvVaw0qm45MWGbZf0zbBjZj3ggz
> 
> 
>Abstract:
>   This document describes how a JavaScript frontend can 

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

[Stoycho Sleptsov]

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-oauth-v2-1-01, through mTLS, Basic
authentication with client secret, "private_key_jwt", or other means).

On Sun, 14 Feb 2021 at 15:53, Warren Parad  wrote:
>
> 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 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

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

[Warren Parad]

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

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

[Stoycho Sleptsov]

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

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

[Warren Parad]

>
> 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 architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci  wrote:

>
>- 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
>redirects.
>
> 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. In code+PKCE you can use a refresh token, but see the
> other reply for how this proposal is an alternative to that in some
> situations. This answer was specifically on why having backend-issued
> tokens didn’t apply to this scenario.
>
>
>
>
>
> *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
> 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 application that
> signs in users using Azure AD, and needs to call Office and Azure APIs. The
> SPA backend cannot issue tokens for those APIs, it can only request them to
> the Azure AD AS.
>
>
>
> 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
> redirects. For RO responsibilities, you can present the user with a button
> "Grant RO access to Azure resources" button and the user will go through a
> permission scope elevation flow, again no reason to need a BFF here.
>
>
>
> We did consider adding something to that effect, an error message that can
> direct the frontend to perform the interactive portion necessary for this
> topology to work. It would be something similar to the IDP initiated login
> in OIDC, where the client offers an endpoint 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 received.
>
> It may make sense for the app to have an error message, or even better
> might be a 302 *Location header* depending on what you are doing. There
> is nothing here that is OAuth specific however (nor common), and then we
> should challenge the need to directly provide an RFC recommendation for
> handling this.
>
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
>
>
>
> On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> 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
> necessary to establish a session (eg sign in, assuming the AS is say an
> OIDC provider) and obtain beforehand the access token and refresh tokens
> that will be needed during the app activities taking place after  that. In
> concrete terms, imagine that the backend performs an authorization code
> grant requesting an IDtoken, access token and refresh token BEFORE the
> activities described in TMI-BFF take place.
>
> The current language trying to express that is in 1.2:
>
> As a prerequisite for the flow described below, the backend MUST have
> established a secure session with the user agent, so that all requests from
> that user agent toward the backend occur over HTTPS and carry a valid
> session artifact (such as a cookie) that the backend can validate. This
> document does not mandate any specific mechanism to establish and maintain
> that session.
>
> And
>
> cached, it requests to the authorization server a new access token with
> the required characteristics, using any artifacts previousy obtained (eg
> refresh token) and grants that will allow the 

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

[Vittorio Bertocci]

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 get out of supporting 
code+PKCE, it’s not. For true SPAs (no backend) that remains the main way for 
enabling frontents to call API. This is  more about trying to take advantage of 
the presence of the backend to make things simpler when viable, and to bring 
some guidance to emerging practices 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 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 standard AS specific services prototypes to support BFF. That means 
that everyone is writing their own BFF AS-proxy.
TMI-BFF does provide a sort of proxy for the AS, but it is very constrained 
both in functionality (only one simple request type) and topology (only one 
requestor type, with assumptions about sessions, origin provenance etc) hence 
the requirements are a very limited subset of a full blown AS.
In terms of everyone doing their own implementation, the intent here is the 
exact opposite. By providing guidance on how to format requests/responses and 
what endpoints to refer to, the implementation details can be factored out from 
individual apps and stacks, facilitating interoperability.


  *   [..] Which isn't ever justified, but even if we accept that as a true 
premise, what are these AS doing that even require a BFF?
I am not sure how to interpret the statement about “ever justified”. This has 
little to do with the authorization server. Not every application can have a 
backend that exposes a façade replicating all the APIs the frontend need to 
invoke, for all sorts of reasons: maintenance, performance, skills of the 
developers involved, capabilities of the stacks of choice, and so on. This 
isn’t theoretical, I had this discussions many times with prospects and 
developers.


  *   Hypothetically you could argue that the auth code flow requires a BFF and 
that's required for user login since implicit flow no longer exists, but that 
isn't true. You can use client side PKCE for validation of these via not 
requiring the client secret in the front end, and then the problem there is 
solved.
In concrete terms, things are a bit more complicated than “a grant for SPAs 
already exist”. I am well aware that code+PKCE is a viable solution for SPAs to 
get access tokens, however that has its own challenges. For example, if you 
want to use refresh tokens in it, you need to sender constrain them or support 
refresh token rotation. If you check the current situation across the industry, 
you’ll see that very few SDKs actually do support rotation or sender constraint 
today- arguably introducing a new security issue. And of course, there’s the 
huge debacle about saving tokens in local storage- something that many 
applications need to do in order to offer the experience their customers 
require.
If a SPA app does not have a backend, code+PKCE is the only game in town. If it 
has a backend AND can leave all actual API calls to it, there’s no need to get 
tokens in the user agent.
But if you are in one situation where you do have a backend and cannot delegate 
API calls (see my preceding comment), then TMI-BFF can get tokens to your 
frontend without requiring complex javascript logic, without having to persist 
anything in local storage and without requiring the AS to support rotation or 
sender constraint. As long as the traffic with bff-token proxy is hardened, I 
would argue TMI-BFF might actually be easier to implement securely that 
code+PKCE+rotation/SC. Having access tokens in the frontend remains not great, 
but it seems that giving people who would do it anyway some guidance is better 
than leaving them at their own device- unless we conclude that this flow cannot 
be secured, in which case I agree we should explicitly idnciate this as anti 
pattern. But so far, it seems still to be demosntrated.


  *   There was also the argument of there are lots of people doing this, which 
is always a terrible argument, but even if we do permit that in the discussion, 
we still need to answer the why. Why are developers creating BFF for their 
frontends to communicate with an AS. Is it because AS are terrible, is it 
because front ends as a service are terrible, etc... Until we know why this is 
happening concretely, I don't think we should encourage further use of a 

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

[Vittorio Bertocci]

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: 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 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 is in-memory or local 
storage) - but this exactly seems to happen in D.

Thanks
———
Dominick Baier


On 12. February 2021 at 21:46:20, Vittorio Bertocci 
(vittorio.bertocci=40auth0@dmarc.ietf.org)
 wrote:
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 is already in use, in proprietary form, by various modern 
development stacks, such as Next.JS. Variants of the pattern, often discussed 
under the catch-all term BFF (backend for frontend), have been often mentioned 
in this workgroup’s activity, but always left all implementation details to the 
reader.
We believe the pattern has merit, as corroborated by its growing adoption. By 
delegating access token acquisition to the backend, we avoid many of the often 
brittle moving parts (and implied attack surface) required to acquire access 
tokens from a user agent. The topology also relieves the frontend from the need 
of persisting tokens in local storage, a well known sore point of using OAuth 
directly in JavaScript, by relying on its backend storage and session to 
preserve tokens.

Although the specification is very simple, providing explicit guidance on the 
scenario offers many advantages.
- It makes it possible to create interoperable SDKs, where frontend dev stacks 
(any JS flavor) can be mixed and matched with compliant backend stacks 
(middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario and 
warn implementers against security risks (scope escalations, using IDtokens 
instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as part 
of the browser apps security guidance, and position the scenario where frontend 
only calls API on its own backed (hence doesn’t need access tokens) simply as a 
special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventing 
developers from weakening the security of their system (eg turning on ROPG 
options) or turning to risky practices like scraping

Needless to say, this specification doesn’t entirely eliminate the risks 
inherent to direct use of access tokens from a browser. But reality is that the 
pattern is in widespread use, and the circumstances leading to that (eg 
developers on a particular project only work with frontend stacks; components 
like reverse proxies might not always be viable; etc) aren’t going away any 
time soon. By providing simple guidance on this pattern, we can simplify the 
life of many developers while enshrining basic security hygiene in scenarios 
that would have otherwise be left to their own device.

Looking forward for your feedback!

B

On 2/12/21, 12:41, "internet-dra...@ietf.org" 
mailto:internet-dra...@ietf.org>> wrote:


A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to the
IETF repository.

Name: draft-bertocci-oauth2-tmi-bff
Revision: 00
Title: Token Mediating and session Information Backend For Frontend
Document date: 2021-02-12
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt
Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


Abstract:
This document describes how a JavaScript frontend can delegate access
token acquisition to a backend component. In so doing, the frontend
can access resource servers directly without taking on the burden of
communicating with the authorization server, persisting tokens, and
performing operations that are fraught with security challenges when
executed in a user agent, but are safe and well proven when executed
by a confidential 

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

[Vittorio Bertocci]

  *   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 redirects.
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. In code+PKCE you can use a refresh token, but see the other reply 
for how this proposal is an alternative to that in some situations. This answer 
was specifically on why having backend-issued tokens didn’t apply to this 
scenario.


From: Warren Parad 
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci 
Cc: Neil Madden , "oauth@ietf.org" 
Subject: 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 application that signs in users using 
Azure AD, and needs to call Office and Azure APIs. The SPA backend cannot issue 
tokens for those APIs, it can only request them to the Azure AD AS.

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 redirects. For 
RO responsibilities, you can present the user with a button "Grant RO access to 
Azure resources" button and the user will go through a permission scope 
elevation flow, again no reason to need a BFF here.

We did consider adding something to that effect, an error message that can 
direct the frontend to perform the interactive portion necessary for this 
topology to work. It would be something similar to the IDP initiated login in 
OIDC, where the client offers an endpoint 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 
received.
It may make sense for the app to have an error message, or even better might be 
a 302 Location header depending on what you are doing. There is nothing here 
that is OAuth specific however (nor common), and then we should challenge the 
need to directly provide an RFC recommendation for handling this.


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress.


On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
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 necessary 
to establish a session (eg sign in, assuming the AS is say an OIDC provider) 
and obtain beforehand the access token and refresh tokens that will be needed 
during the app activities taking place after  that. In concrete terms, imagine 
that the backend performs an authorization code grant requesting an IDtoken, 
access token and refresh token BEFORE the activities described in TMI-BFF take 
place.
The current language trying to express that is in 1.2:
As a prerequisite for the flow described below, the backend MUST have 
established a secure session with the user agent, so that all requests from 
that user agent toward the backend occur over HTTPS and carry a valid session 
artifact (such as a cookie) that the backend can validate. This document does 
not mandate any specific mechanism to establish and maintain that session.
And
cached, it requests to the authorization server a new access token with the 
required characteristics, using any artifacts previousy obtained (eg refresh 
token) and grants that will allow the authorization server to issue the 
requested token without requiring user interaction.


  *If the backend is already implicitly trusted then couldn’t you skip 
OAuth and just get the backend to issue short-lived JWTs to the frontend that 
it can use for API access?
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 application that signs in users using 
Azure AD, and needs to call Office 

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

[Vittorio Bertocci]

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 standard AS specific services prototypes to support BFF. That means 
that everyone is writing their own BFF AS-proxy.
TMI-BFF does provide a sort of proxy for the AS, but it is very constrained 
both in functionality (only one simple request type) and topology (only one 
requestor type, with assumptions about sessions, origin provenance etc) hence 
the requirements are a very limited subset of a full blown AS.
In terms of everyone doing their own implementation, the intent here is the 
exact opposite. By providing guidance on how to format requests/responses and 
what endpoints to refer to, the implementation details can be factored out from 
individual apps and stacks, facilitating interoperability.


  *   [..] Which isn't ever justified, but even if we accept that as a true 
premise, what are these AS doing that even require a BFF?
I am not sure how to interpret the statement about “ever justified”. This has 
little to do with the authorization server. Not every application can have a 
backend that exposes a façade replicating all the APIs the frontend need to 
invoke, for all sorts of reasons: maintenance, performance, skills of the 
developers involved, capabilities of the stacks of choice, and so on. This 
isn’t theoretical, I had this discussions many times with prospects and 
developers.


  *   Hypothetically you could argue that the auth code flow requires a BFF and 
that's required for user login since implicit flow no longer exists, but that 
isn't true. You can use client side PKCE for validation of these via not 
requiring the client secret in the front end, and then the problem there is 
solved.
In concrete terms, things are a bit more complicated than “a grant for SPAs 
already exist”. I am well aware that code+PKCE is a viable solution for SPAs to 
get access tokens, however that has its own challenges. For example, if you 
want to use refresh tokens in it, you need to sender constrain them or support 
refresh token rotation. If you check the current situation across the industry, 
you’ll see that very few SDKs actually do support rotation or sender constraint 
today- arguably introducing a new security issue. And of course, there’s the 
huge debacle about saving tokens in local storage- something that many 
applications need to do in order to offer the experience their customers 
require.
If a SPA app does not have a backend, code+PKCE is the only game in town. If it 
has a backend AND can leave all actual API calls to it, there’s no need to get 
tokens in the user agent.
But if you are in one situation where you do have a backend and cannot delegate 
API calls (see my preceding comment), then TMI-BFF can get tokens to your 
frontend without requiring complex javascript logic, without having to persist 
anything in local storage and without requiring the AS to support rotation or 
sender constraint. As long as the traffic with bff-token proxy is hardened, I 
would argue TMI-BFF might actually be easier to implement securely that 
code+PKCE+rotation/SC. Having access tokens in the frontend remains not great, 
but it seems that giving people who would do it anyway some guidance is better 
than leaving them at their own device- unless we conclude that this flow cannot 
be secured, in which case I agree we should explicitly idnciate this as anti 
pattern. But so far, it seems still to be demosntrated.


  *   There was also the argument of there are lots of people doing this, which 
is always a terrible argument, but even if we do permit that in the discussion, 
we still need to answer the why. Why are developers creating BFF for their 
frontends to communicate with an AS. Is it because AS are terrible, is it 
because front ends as a service are terrible, etc... Until we know why this is 
happening concretely, I don't think we should encourage further use of a 
pattern rife with potential security risks by telling everyone how you can do 
it (because the guidance we are offering doesn't even slightly increase safety).
The preceding comments should have shed more light about the why, and on some 
of the security concerns (there was one concern raised by Neil, and it seems 
there are possible mitigations in place) plus how this might actually increase 
safety in some aspects. But to add more color, one of the other reasons for 
which this is happening is because it’s simple. Backend OAUth/OIDC SDKs like 
middlewares and similar are very mature at this point, and they aren’t saddled 
by a lot of the complexity and uncertainly that browser based SDKs carry. 
Things like IE zones, ITP, SameSite and our own changing guidance (for good 
reasons) plus disomogeneous support from providers of the features 

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

[Warren Parad]

>
> 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 technically support) it will always be available to Javascript in
browser, right?

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 1:06 PM Dominick Baier 
wrote:

> 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 is in-memory or
> local storage) - but this exactly seems to happen in D.
>
> Thanks
> ———
> Dominick Baier
>
> On 12. February 2021 at 21:46:20, Vittorio Bertocci (
> vittorio.bertocci=40auth0@dmarc.ietf.org) wrote:
>
> 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 is already in use, in proprietary form, by various modern
> development stacks, such as Next.JS. Variants of the pattern, often
> discussed under the catch-all term BFF (backend for frontend), have been
> often mentioned in this workgroup’s activity, but always left all
> implementation details to the reader.
> We believe the pattern has merit, as corroborated by its growing adoption.
> By delegating access token acquisition to the backend, we avoid many of the
> often brittle moving parts (and implied attack surface) required to acquire
> access tokens from a user agent. The topology also relieves the frontend
> from the need of persisting tokens in local storage, a well known sore
> point of using OAuth directly in JavaScript, by relying on its backend
> storage and session to preserve tokens.
>
> Although the specification is very simple, providing explicit guidance on
> the scenario offers many advantages.
> - It makes it possible to create interoperable SDKs, where frontend dev
> stacks (any JS flavor) can be mixed and matched with compliant backend
> stacks (middlewares in node, java, ASP.NET, PHP etc)
> - It allows us to provide guidance on how to properly tackle the scenario
> and warn implementers against security risks (scope escalations, using
> IDtokens instead of access tokens, etc)
> - It allows us to discuss (and when appropriate, promote) this pattern as
> part of the browser apps security guidance, and position the scenario where
> frontend only calls API on its own backed (hence doesn’t need access
> tokens) simply as a special case of this more general pattern
> - This approach makes mocking and testing apps very easy, possibly
> preventing developers from weakening the security of their system (eg
> turning on ROPG options) or turning to risky practices like scraping
>
> Needless to say, this specification doesn’t entirely eliminate the risks
> inherent to direct use of access tokens from a browser. But reality is that
> the pattern is in widespread use, and the circumstances leading to that (eg
> developers on a particular project only work with frontend stacks;
> components like reverse proxies might not always be viable; etc) aren’t
> going away any time soon. By providing simple guidance on this pattern, we
> can simplify the life of many developers while enshrining basic security
> hygiene in scenarios that would have otherwise be left to their own device.
>
> Looking forward for your feedback!
>
> B
>
> On 2/12/21, 12:41, "internet-dra...@ietf.org" 
> wrote:
>
>
> A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
> has been successfully submitted by Vittorio Bertocci and posted to the
> IETF repository.
>
> Name: draft-bertocci-oauth2-tmi-bff
> Revision: 00
> Title: Token Mediating and session Information Backend For Frontend
> Document date: 2021-02-12
> Group: Individual Submission
> Pages: 16
> URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt
> Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
> Html:
> https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
> Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00
>
>
> Abstract:
> This document describes how a JavaScript frontend can delegate access
> token acquisition to a backend component. In so doing, the frontend
> can access resource servers directly without taking on the burden of
> communicating with the authorization server, persisting tokens, and
> performing operations that are fraught with security challenges when
> executed in a user agent, 

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

[Dominick Baier]

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 is in-memory or
local storage) - but this exactly seems to happen in D.

Thanks
———
Dominick Baier

On 12. February 2021 at 21:46:20, Vittorio Bertocci (
vittorio.bertocci=40auth0@dmarc.ietf.org) wrote:

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 is already in use, in proprietary form, by various modern
development stacks, such as Next.JS. Variants of the pattern, often
discussed under the catch-all term BFF (backend for frontend), have been
often mentioned in this workgroup’s activity, but always left all
implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption.
By delegating access token acquisition to the backend, we avoid many of the
often brittle moving parts (and implied attack surface) required to acquire
access tokens from a user agent. The topology also relieves the frontend
from the need of persisting tokens in local storage, a well known sore
point of using OAuth directly in JavaScript, by relying on its backend
storage and session to preserve tokens.

Although the specification is very simple, providing explicit guidance on
the scenario offers many advantages.
- It makes it possible to create interoperable SDKs, where frontend dev
stacks (any JS flavor) can be mixed and matched with compliant backend
stacks (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario
and warn implementers against security risks (scope escalations, using
IDtokens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as
part of the browser apps security guidance, and position the scenario where
frontend only calls API on its own backed (hence doesn’t need access
tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly
preventing developers from weakening the security of their system (eg
turning on ROPG options) or turning to risky practices like scraping

Needless to say, this specification doesn’t entirely eliminate the risks
inherent to direct use of access tokens from a browser. But reality is that
the pattern is in widespread use, and the circumstances leading to that (eg
developers on a particular project only work with frontend stacks;
components like reverse proxies might not always be viable; etc) aren’t
going away any time soon. By providing simple guidance on this pattern, we
can simplify the life of many developers while enshrining basic security
hygiene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B

On 2/12/21, 12:41, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to the
IETF repository.

Name: draft-bertocci-oauth2-tmi-bff
Revision: 00
Title: Token Mediating and session Information Backend For Frontend
Document date: 2021-02-12
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt
Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


Abstract:
This document describes how a JavaScript frontend can delegate access
token acquisition to a backend component. In so doing, the frontend
can access resource servers directly without taking on the burden of
communicating with the authorization server, persisting tokens, and
performing operations that are fraught with security challenges when
executed in a user agent, but are safe and well proven when executed
by a confidential client running on a backend.




Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

>
> 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 application that
> signs in users using Azure AD, and needs to call Office and Azure APIs. The
> SPA backend cannot issue tokens for those APIs, it can only request them to
> the Azure AD AS.


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
redirects. For RO responsibilities, you can present the user with a button
"Grant RO access to Azure resources" button and the user will go through a
permission scope elevation flow, again no reason to need a BFF here.

We did consider adding something to that effect, an error message that can
> direct the frontend to perform the interactive portion necessary for this
> topology to work. It would be something similar to the IDP initiated login
> in OIDC, where the client offers an endpoint 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 received.

It may make sense for the app to have an error message, or even better
might be a 302 *Location header* depending on what you are doing. There is
nothing here that is OAuth specific however (nor common), and then we
should challenge the need to directly provide an RFC recommendation for
handling this.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci  wrote:

> 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
> necessary to establish a session (eg sign in, assuming the AS is say an
> OIDC provider) and obtain beforehand the access token and refresh tokens
> that will be needed during the app activities taking place after  that. In
> concrete terms, imagine that the backend performs an authorization code
> grant requesting an IDtoken, access token and refresh token BEFORE the
> activities described in TMI-BFF take place.
>
> The current language trying to express that is in 1.2:
>
> As a prerequisite for the flow described below, the backend MUST have
> established a secure session with the user agent, so that all requests from
> that user agent toward the backend occur over HTTPS and carry a valid
> session artifact (such as a cookie) that the backend can validate. This
> document does not mandate any specific mechanism to establish and maintain
> that session.
>
> And
>
> cached, it requests to the authorization server a new access token with
> the required characteristics, using any artifacts previousy obtained (eg
> refresh token) and grants that will allow the authorization server to issue
> the requested token without requiring user interaction.
>
>
>
>-  If the backend is already implicitly trusted then couldn’t you skip
>OAuth and just get the backend to issue short-lived JWTs to the frontend
>that it can use for API access?
>
> 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 application that
> signs in users using Azure AD, and needs to call Office and Azure APIs. The
> SPA backend cannot issue tokens for those APIs, it can only request them to
> the Azure AD AS.
>
>
>
>- If you want to allow auth code flow etc then perhaps the bff-token
>endpoint can return a standard error code with an authorization endpoint
>URI that the SPA then navigates the user to. (Eg the backend can do a PAR
>request first and return a URI that references that so that authorization
>details aren’t passed through the frontend).
>
> We did consider adding something to that effect, an error message that can
> direct the frontend to perform the interactive portion necessary for this
> topology to work. It would be something similar to the IDP initiated login
> in OIDC, where the client offers an endpoint 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 

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

[Vittorio Bertocci]

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 necessary 
to establish a session (eg sign in, assuming the AS is say an OIDC provider) 
and obtain beforehand the access token and refresh tokens that will be needed 
during the app activities taking place after  that. In concrete terms, imagine 
that the backend performs an authorization code grant requesting an IDtoken, 
access token and refresh token BEFORE the activities described in TMI-BFF take 
place.
The current language trying to express that is in 1.2:
As a prerequisite for the flow described below, the backend MUST have 
established a secure session with the user agent, so that all requests from 
that user agent toward the backend occur over HTTPS and carry a valid session 
artifact (such as a cookie) that the backend can validate. This document does 
not mandate any specific mechanism to establish and maintain that session.
And
cached, it requests to the authorization server a new access token with the 
required characteristics, using any artifacts previousy obtained (eg refresh 
token) and grants that will allow the authorization server to issue the 
requested token without requiring user interaction.


  *If the backend is already implicitly trusted then couldn’t you skip 
OAuth and just get the backend to issue short-lived JWTs to the frontend that 
it can use for API access?
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 application that signs in users using 
Azure AD, and needs to call Office and Azure APIs. The SPA backend cannot issue 
tokens for those APIs, it can only request them to the Azure AD AS.


  *   If you want to allow auth code flow etc then perhaps the bff-token 
endpoint can return a standard error code with an authorization endpoint URI 
that the SPA then navigates the user to. (Eg the backend can do a PAR request 
first and return a URI that references that so that authorization details 
aren’t passed through the frontend).
We did consider adding something to that effect, an error message that can 
direct the frontend to perform the interactive portion necessary for this 
topology to work. It would be something similar to the IDP initiated login in 
OIDC, where the client offers an endpoint 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 
received.

From: OAuth  on 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 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. To do this you’d need an XSS attack. But in that case, wouldn’t the 
attacker simply use the XSS to make a call to the bff-token endpoint instead?

The combination of the bff-token endpoint recommending the use of GET requests 
together with the hint to use cookie-based authentication is likely going to 
punch a hole in most CSRF defenses, which assume that GETs are safe. The only 
thing preventing this being exploitable is Cross-Origin Read Blocking 
(https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md)
 due to the JSON content-type. That makes me really nervous. We should at least 
mandate X-Content-Type-Options: nosniff on that response. I’d feel more 
comfortable if this was a POST request only.

As Stoycho Sleptsov mentioned in the other email, the lack of front-channel 
communication between the AS and the RO seems odd. If the backend is already 
implicitly trusted then couldn’t you skip OAuth and just get the backend to 
issue short-lived JWTs to the frontend that it can use for API access?

If you want to allow auth code flow etc then perhaps the bff-token endpoint can 
return a standard error code with an authorization endpoint URI that the SPA 
then navigates the user to. (Eg the backend can do a PAR request first and 
return a URI that references that so that authorization details aren’t passed 
through the frontend).

— Neil



On 12 Feb 2021, at 20:46, Vittorio Bertocci 
 wrote:
Dear all,
Brian 

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

[Vittorio Bertocci]

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 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)

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 now, and the corresponding APIs 
(resource servers). Our team will also have to implement some initial frontend 
applications which will
consume those exposed resources. I was exactly at the point of considering how 
to organise the correspondence of the access token from the auth server to the 
frontend and from the frontend to the
resource servers, when I received as a very nice surprise the news about 
tmi-bff draft. It was such a relief, as the option to delegate access token 
acquisition to a backend component, while still accessing resource servers 
directly from the frontend, seemed most suitable and
well balanced for our case.

I have read the draft with great pleasure, but one thing concerns me in it.

In the description of the protocol flow (1.2), in the step of token request 
from backend to AS (step B), it mentions that the AS should "issue the 
requested token without requiring user interaction". Same
thing is reconfirmed in section 4, step 4: "the backend verifies whether it has 
the necessary artifacts to request it to the
authorization server without requiring user interaction".

But an initial interaction between the resource owner and the authorization 
server is required by the authorization code flow (section 1.3.1 of the 
draft-ietf-oauth-v2-1-01).

So where does this interaction fit in the tmi-bff protocol flow? Or tmi-bff is 
not supposed to be used with authorization code flow?

Thank you for your time,
hoping to hear from you,
Stoycho.

На пт, 12 фев 2021 г., 22:46 Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 написа:
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 is already in use, in proprietary form, by various modern 
development stacks, such as Next.JS. Variants of the pattern, often discussed 
under the catch-all term BFF (backend for frontend), have been often mentioned 
in this workgroup’s activity, but always left all implementation details to the 
reader.
We believe the pattern has merit, as corroborated by its growing adoption. By 
delegating access token acquisition to the backend, we avoid many of the often 
brittle moving parts (and implied attack surface) required to acquire access 
tokens from a user agent. The topology also relieves the frontend from the need 
of persisting tokens in local storage, a well known sore point of using OAuth 
directly in JavaScript, by relying on its backend storage and session to 
preserve tokens.

Although the specification is very simple, providing explicit guidance on the 
scenario offers many advantages.
- It makes it possible to create interoperable SDKs, where frontend dev stacks 
(any JS flavor) can be mixed and matched with compliant backend stacks 
(middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario and 
warn implementers against security risks (scope escalations, using IDtokens 
instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as part 
of the browser apps security guidance, and position the scenario where frontend 
only calls API on its own backed (hence doesn’t need access tokens) simply as a 
special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventing 
developers from weakening the security of their system (eg turning on ROPG 
options)  or turning to risky practices like scraping

Needless to say, this specification doesn’t entirely eliminate the risks 
inherent to direct use of access tokens from a browser. But reality is that the 
pattern is in widespread use, and the circumstances leading to that (eg 
developers on a particular project only work with frontend stacks; components 
like reverse proxies might not always be viable; etc) aren’t going away any 
time soon. By providing simple guidance on this 

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

[Warren Parad]

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 services prototypes to support BFF. That means that everyone is
writing their own BFF AS-proxy.

Additionally, I too am lacking the clarity on the *WHY*. The only thing
mentioned in the draft is

> That approach is not always viable, as in the absence of reverse proxy
> deployments the creation and maintenance of a facade for multiple APIs can
> be expensive

Which isn't ever justified, but even if we accept that as a true premise,
what are these AS doing that even require a BFF?

Hypothetically you could argue that the auth code flow requires a BFF and
that's required for user login since implicit flow no longer exists, but
that isn't true. You can use client side PKCE for validation of these via
not requiring the client secret in the front end, and then the problem
there is solved. And if you argue that this can't be done, then the
solution is introducing a better way to handle this so that a BFF for AS
flows don't have to exist.

So what concrete problem is this solving?

There was also the argument of *there are lots of people doing this*, which
is always a terrible argument, but even if we do permit that in the
discussion, we still need to answer the *why. *Why are developers creating
BFF for their frontends to communicate with an AS. Is it because AS are
terrible, is it because *front ends as a service* are terrible, etc...
Until we know why this is happening concretely, I don't think we should
encourage further use of a pattern rife with potential security risks by
telling everyone how you can do it (because the guidance we are offering
doesn't even slightly increase safety).

Further, even if we were to accept this pattern and want to create a
standard around it, we are effectively creating an AS proxy here, which
means we should require it to act like an AS, and delegate the
specification of resources, endpoints, terminology, and patterns to
existing or future AS related RFCs. (We already have a problem with the
current draft as it attempts to redefine and introduce new terms/patterns
that have the same functionality as existing ones in the AS, yet fail to
capture the full importance of the original RFCs. This is bad duplication).
And therefore in conclusion we should focus only on the aspects that are
absolutely required which aren't already present in some form in existing
AS related RFCs, but what are those?

The one counterpoint to all of this is the potential introduction of domain
specific *cookie* language (which doesn't exist in the current draft).
Concretely, *let's add a response_type=cookie*, to AS to support domain
first-party cookies and session management. When we built our AS we
explicitly added this so that services can use the JWT found in the
HttpOnly SameSite=Strict cookie as a security measure against XSS attacks
that attempt to exfiltrate access tokens. That's a potential suggestion I
would favor, although I still can't know if that solves the problem being
presented in the draft.

- Warren

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress .


On Sun, Feb 14, 2021 at 9:18 AM Neil Madden 
wrote:

> 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. To do this you’d need an XSS attack. But in that
> case, wouldn’t the attacker simply use the XSS to make a call to the
> bff-token endpoint instead?
>
> The combination of the bff-token endpoint recommending the use of GET
> requests together with the hint to use cookie-based authentication is
> likely going to punch a hole in most CSRF defenses, which assume that GETs
> are safe. The only thing preventing this being exploitable is Cross-Origin
> Read Blocking (
> https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md)
> due to the JSON content-type. That makes me really nervous. We should at
> least mandate X-Content-Type-Options: nosniff on that response. I’d feel
> more comfortable if this was a POST request only.
>
> As Stoycho Sleptsov mentioned in the other email, the lack of
> front-channel communication between the AS and the RO seems odd. If the
> backend is already implicitly trusted then couldn’t you skip OAuth and just
> get the backend to issue short-lived JWTs to the frontend that it can use
> for API access?
>
> If you want to allow auth code flow etc then perhaps the bff-token
> endpoint can return a standard error code with an 

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

[Neil Madden]

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. To do this you’d need an XSS attack. But in that case, wouldn’t the 
attacker simply use the XSS to make a call to the bff-token endpoint instead? 

The combination of the bff-token endpoint recommending the use of GET requests 
together with the hint to use cookie-based authentication is likely going to 
punch a hole in most CSRF defenses, which assume that GETs are safe. The only 
thing preventing this being exploitable is Cross-Origin Read Blocking 
(https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md)
 due to the JSON content-type. That makes me really nervous. We should at least 
mandate X-Content-Type-Options: nosniff on that response. I’d feel more 
comfortable if this was a POST request only. 

As Stoycho Sleptsov mentioned in the other email, the lack of front-channel 
communication between the AS and the RO seems odd. If the backend is already 
implicitly trusted then couldn’t you skip OAuth and just get the backend to 
issue short-lived JWTs to the frontend that it can use for API access?

If you want to allow auth code flow etc then perhaps the bff-token endpoint can 
return a standard error code with an authorization endpoint URI that the SPA 
then navigates the user to. (Eg the backend can do a PAR request first and 
return a URI that references that so that authorization details aren’t passed 
through the frontend). 

— Neil


> On 12 Feb 2021, at 20:46, Vittorio Bertocci 
>  wrote:
> 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 is already in use, in proprietary form, by various modern 
> development stacks, such as Next.JS. Variants of the pattern, often discussed 
> under the catch-all term BFF (backend for frontend), have been often 
> mentioned in this workgroup’s activity, but always left all implementation 
> details to the reader.
> We believe the pattern has merit, as corroborated by its growing adoption. By 
> delegating access token acquisition to the backend, we avoid many of the 
> often brittle moving parts (and implied attack surface) required to acquire 
> access tokens from a user agent. The topology also relieves the frontend from 
> the need of persisting tokens in local storage, a well known sore point of 
> using OAuth directly in JavaScript, by relying on its backend storage and 
> session to preserve tokens.
> 
> Although the specification is very simple, providing explicit guidance on the 
> scenario offers many advantages.  
> - It makes it possible to create interoperable SDKs, where frontend dev 
> stacks (any JS flavor) can be mixed and matched with compliant backend stacks 
> (middlewares in node, java, ASP.NET, PHP etc)
> - It allows us to provide guidance on how to properly tackle the scenario and 
> warn implementers against security risks (scope escalations, using IDtokens 
> instead of access tokens, etc)
> - It allows us to discuss (and when appropriate, promote) this pattern as 
> part of the browser apps security guidance, and position the scenario where 
> frontend only calls API on its own backed (hence doesn’t need access tokens) 
> simply as a special case of this more general pattern
> - This approach makes mocking and testing apps very easy, possibly preventing 
> developers from weakening the security of their system (eg turning on ROPG 
> options)  or turning to risky practices like scraping
> 
> Needless to say, this specification doesn’t entirely eliminate the risks 
> inherent to direct use of access tokens from a browser. But reality is that 
> the pattern is in widespread use, and the circumstances leading to that (eg 
> developers on a particular project only work with frontend stacks; components 
> like reverse proxies might not always be viable; etc) aren’t going away any 
> time soon. By providing simple guidance on this pattern, we can simplify the 
> life of many developers while enshrining basic security hygiene in scenarios 
> that would have otherwise be left to their own device.
> 
> Looking forward for your feedback!
> 
> B  
> 
> On 2/12/21, 12:41, "internet-dra...@ietf.org"  
> wrote:
> 
> 
>A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
>has been successfully submitted by Vittorio Bertocci and posted to the
>IETF repository.
> 
>Name:draft-bertocci-oauth2-tmi-bff
>Revision:00
>Title:Token Mediating and session Information Backend For Frontend
>Document