Thank you again for the explanation. I think your assumption about the overall flow should be described in the draft.
As I understand it now the core contribution of your proposal is to move refresh token management from frontend to backend. Is that correct? > Am 14.02.2021 um 21:35 schrieb Vittorio Bertocci > <vittorio.bertocci=40auth0....@dmarc.ietf.org>: > > 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" > <torsten=40lodderstedt....@dmarc.ietf.org> 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 >> <vittorio.bertocci=40auth0....@dmarc.ietf.org>: >> >> 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" >> <torsten=40lodderstedt....@dmarc.ietf.org> 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 >>> <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.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw3Rb-S0l6cEv0ytjDxtYLAP%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw3p5263a_rEePNbnX7jWFjq&source=gmail-imap&ust=1613939757000000&usg=AOvVaw0jgXsBeXKFC9n31Rg06yE6 >>> Status: >>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw3-qg5MDtY7kD1HpR5jR2QY%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw1YZmVHpENHa-bqqtbezRpa&source=gmail-imap&ust=1613939757000000&usg=AOvVaw0UWVw3PhVKKuwdIjaMHfce >>> Html: >>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw05WK4GSEKcWjZzNhvb1p5d%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw2HibfQtTYv3talGT379MOu&source=gmail-imap&ust=1613939757000000&usg=AOvVaw3AuwQ6TPoW5MnsGXcMUh_S >>> Htmlized: >>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw0qm45MWGbZf0zbBjZj3ggz%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw0gZZ0ZU8QVx7OBjxDcG8d-&source=gmail-imap&ust=1613939757000000&usg=AOvVaw2fIy9b1bQxvnk5QK9Nl7QI >>> >>> >>> 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.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.ietf.org/mailman/listinfo/oauth%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw1Bfu9fJ2Fj_BZJ3H9yw7od%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw3a73buBtPOBoDQ3SMH_XJW&source=gmail-imap&ust=1613939757000000&usg=AOvVaw3p0jGqda5qiL2KioFSSZ01 >> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
