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