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

[Torsten Lodderstedt <[e-mail]>]

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=[e-mail]>:
> 
> 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=[e-mail]> 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=[e-mail]>:
>> 
>> 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=[e-mail]> 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=[e-mail]>:
>>> 
>>> 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, "[e-mail]" <[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.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
>>> [e-mail]
>>> 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
>> 
>> 
>