> > 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 <vittorio.bertocci= 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 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=40rhosys...@dmarc.ietf.org> > *Date: *Sunday, February 14, 2021 at 11:41 > *To: *Vittorio Bertocci <vittorio.berto...@auth0.com> > *Cc: *Neil Madden <neil.mad...@forgerock.com>, "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 <https://authress.io>. > > > > > > On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci <vittorio.bertocci= > 40auth0....@dmarc.ietf.org> wrote: > > ITP, for example > > > > *From: *Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > *Date: *Sunday, February 14, 2021 at 04:54 > *To: *Vittorio Bertocci <vittorio.berto...@auth0.com> > *Cc: *Neil Madden <neil.mad...@forgerock.com>, "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? > > > *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= > 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 <wparad=40rhosys...@dmarc.ietf.org> > *Date: *Sunday, February 14, 2021 at 03:48 > *To: *Vittorio Bertocci <vittorio.berto...@auth0.com> > *Cc: *Neil Madden <neil.mad...@forgerock.com>, "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 <https://authress.io>. > > > > > > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci <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 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 <oauth-boun...@ietf.org> on behalf of Neil Madden < > neil.mad...@forgerock.com> > *Date: *Sunday, February 14, 2021 at 00:17 > *To: *Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org> > *Cc: *"oauth@ietf.org" <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 <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&V > > On 2/12/21, 12:41, "internet-dra...@ietf.org" <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 > > > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> > > _______________________________________________ > 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
