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

[Warren Parad <[e-mail]>]

I also flat out reject the premise of this draft. It introduces a pseudo
AS-like proxy which now has all the requirements of an AS and more. While
AS SDKs provide easy ways for client UIs to effectively deal with
communication via the AS, there's no way for the AS to provide standard AS
specific services prototypes to support BFF. That means that everyone is
writing their own BFF AS-proxy.

Additionally, I too am lacking the clarity on the *WHY*. The only thing
mentioned in the draft is

> That approach is not always viable, as in the absence of reverse proxy
> deployments the creation and maintenance of a facade for multiple APIs can
> be expensive

Which isn't ever justified, but even if we accept that as a true premise,
what are these AS doing that even require a BFF?

Hypothetically you could argue that the auth code flow requires a BFF and
that's required for user login since implicit flow no longer exists, but
that isn't true. You can use client side PKCE for validation of these via
not requiring the client secret in the front end, and then the problem
there is solved. And if you argue that this can't be done, then the
solution is introducing a better way to handle this so that a BFF for AS
flows don't have to exist.

So what concrete problem is this solving?

There was also the argument of *there are lots of people doing this*, which
is always a terrible argument, but even if we do permit that in the
discussion, we still need to answer the *why. *Why are developers creating
BFF for their frontends to communicate with an AS. Is it because AS are
terrible, is it because *front ends as a service* are terrible, etc...
Until we know why this is happening concretely, I don't think we should
encourage further use of a pattern rife with potential security risks by
telling everyone how you can do it (because the guidance we are offering
doesn't even slightly increase safety).

Further, even if we were to accept this pattern and want to create a
standard around it, we are effectively creating an AS proxy here, which
means we should require it to act like an AS, and delegate the
specification of resources, endpoints, terminology, and patterns to
existing or future AS related RFCs. (We already have a problem with the
current draft as it attempts to redefine and introduce new terms/patterns
that have the same functionality as existing ones in the AS, yet fail to
capture the full importance of the original RFCs. This is bad duplication).
And therefore in conclusion we should focus only on the aspects that are
absolutely required which aren't already present in some form in existing
AS related RFCs, but what are those?

The one counterpoint to all of this is the potential introduction of domain
specific *cookie* language (which doesn't exist in the current draft).
Concretely, *let's add a response_type=cookie*, to AS to support domain
first-party cookies and session management. When we built our AS we
explicitly added this so that services can use the JWT found in the
HttpOnly SameSite=Strict cookie as a security measure against XSS attacks
that attempt to exfiltrate access tokens. That's a potential suggestion I
would favor, although I still can't know if that solves the problem being
presented in the draft.

- Warren

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.


On Sun, Feb 14, 2021 at 9:18 AM Neil Madden <[e-mail]>
wrote:

> 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=
> [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
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>