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

[Dominick Baier <[e-mail]>]

Hi,

Just making sure I understand - in your protocol flow diagram step D it
looks like that the BFF is returning the access token to the front-end. Is
that correct?

My biggest concern with browser-based applications is that the JavaScript /
browser has access to the access token (don’t care if it is in-memory or
local storage) - but this exactly seems to happen in D.

Thanks
———
Dominick Baier

On 12. February 2021 at 21:46:20, Vittorio Bertocci (
vittorio.bertocci=[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, 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.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
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth