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

[Vittorio Bertocci <[e-mail]>]

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 <[e-mail]>
Date: Sunday, February 14, 2021 at 22:45
To: Vittorio Bertocci <[e-mail]>
Cc: Warren Parad <[e-mail]>, "[e-mail]" <[e-mail]>
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 <vittorio.bertocci=[e-mail]<mailto:vittorio.bertocci=[e-mail]>> 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 <wparad=[e-mail]<mailto:wparad=[e-mail]>>
Date: Sunday, February 14, 2021 at 12:59
To: Vittorio Bertocci <[e-mail]<mailto:[e-mail]>>
Cc: Neil Madden <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <vittorio.bertocci=[e-mail]<mailto:[e-mail]>> 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 <wparad=[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 14, 2021 at 11:41
To: Vittorio Bertocci <[e-mail]<mailto:[e-mail]>>
Cc: Neil Madden <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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?

Error! Filename not specified.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement Authress<https://authress.io/>.


On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci <vittorio.bertocci=[e-mail]<mailto:[e-mail]>> wrote:
ITP, for example

From: Warren Parad <wparad=[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 14, 2021 at 04:54
To: Vittorio Bertocci <[e-mail]<mailto:[e-mail]>>
Cc: Neil Madden <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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<https://authress.io/>.


On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci <vittorio.bertocci=[e-mail]<mailto:[e-mail]>> 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 <wparad=[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci <[e-mail]<mailto:[e-mail]>>
Cc: Neil Madden <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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<https://authress.io/>.


On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci <vittorio.bertocci=[e-mail]<mailto:[e-mail]>> 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 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 <[e-mail]<mailto:[e-mail]>> on behalf of Neil Madden <[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 14, 2021 at 00:17
To: Vittorio Bertocci <vittorio.bertocci=[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <vittorio.bertocci=[e-mail]<mailto:[e-mail]>> 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<http://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&V

?On 2/12/21, 12:41, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> 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<http://tools.ietf.org/>.

   The IETF Secretariat



_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

ForgeRock values your Privacy<https://www.forgerock.com/your-privacy>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth