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

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 14 February 2021 14:11 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E423A0C7A for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 06:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PG80EJBb55y for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 06:11:53 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611543A0C70 for <oauth@ietf.org>; Sun, 14 Feb 2021 06:11:53 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id g6so5396674wrs.11 for <oauth@ietf.org>; Sun, 14 Feb 2021 06:11:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Uvn4PvhC2I3cEmvpv2sDXfJbPIcIdRlU1r9X+ABpl+Y=; b=wBI3PFz51O6i79F5ysuzFMSyeJsm3p03wp/pV4WZ2M+v3CxGgwjmM78FzOVAtLdkRG S4AeMbNkIMbtZL5NHi74G1tqHYM/f5HDRzyGtsW03BtUF3UFhhYY58w8wyZnxSYtQdZh k2QaxKvTLGHGHHj9wfmVMjhCWwItXr9JsgOLViPHycQeSe1AvS7jmG92kNA2iejciq5j DRbSV0Q30y3qYhS59HgCHzX1cV6fxl0ok/zZBfvoS84X3WJMqhPgv62yAMQRpBzIgoxM vDGA4pDLFReiJ8ApckmN8UBZcZGcK0swngA0ICKa/ottNBx7hd9ksRa/UG0KaD5pR9iE tamQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Uvn4PvhC2I3cEmvpv2sDXfJbPIcIdRlU1r9X+ABpl+Y=; b=t3fdyhRzUtkt9qmo8wf99wHuvKfYNNuNuRav33YFoNu6NKrCtOovZBprBQWv6432LW etNTYY/tEjdWF72EdAE6B2fKO8X7EzjthF7FaxzQ0YnjU+Cte71NOHiJ7QMOp1nASguz 3Iejpe+1OZI9gI38oHJ9MJPuNP1NqziBDfSFgOCMbYG32ZWlIXHnut5iyisewnzAv+yD tsoFnHWAGcnG3Dq/V56Yem28sDT+ItceA8JMFLbR1Wt26YiMAp7Vop13m3ZQ1eO0QyJ4 48gR7ax14EF0zjnBbDx2KXBuhr/X3w86toZw13P4Ut/vGGw/mCLWPXosIRZJZnRl1EN7 kyDw==
X-Gm-Message-State: AOAM532RvcCHdxhkMEThIA7ochC/dKl7mRclJw2K7L6Ay1o9yH3xI1Jf isyKTqL/AdEE2QO2+jDgOdp2jU/ufgWJSQ9H
X-Google-Smtp-Source: ABdhPJyOMh3gUcba55TU8GpP0knwX6kzkhulhwLu0rEWySEVCkpog85xPvOzeeB7dA6VzqJ3YTRNaA==
X-Received: by 2002:a5d:6951:: with SMTP id r17mr2863054wrw.279.1613311911704; Sun, 14 Feb 2021 06:11:51 -0800 (PST)
Received: from p200300eb8f061195608d66025bbab74b.dip0.t-ipconnect.de (p200300eb8f061195608d66025bbab74b.dip0.t-ipconnect.de. [2003:eb:8f06:1195:608d:6602:5bba:b74b]) by smtp.gmail.com with ESMTPSA id s14sm1116666wmj.23.2021.02.14.06.11.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 06:11:51 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CO6PR18MB4052805653BFECD35E8A0E66AE8B9@CO6PR18MB4052.namprd18.prod.outlook.com>
Date: Sun, 14 Feb 2021 15:11:48 +0100
Cc: "oauth@ietf.org" <oauth@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C900D877-099D-49AE-9138-E5B140F5086F@lodderstedt.net>
References: <CO6PR18MB4052805653BFECD35E8A0E66AE8B9@CO6PR18MB4052.namprd18.prod.outlook.com>
To: Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/62T6hMuQcEUvDEoX71dKmpRPg-4>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Feb 2021 14:11:55 -0000

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.com@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-drafts@ietf.org" <internet-drafts@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.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt&source=gmail-imap&ust=1613767591000000&usg=AOvVaw3Rb-S0l6cEv0ytjDxtYLAP
>    Status:         https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/&source=gmail-imap&ust=1613767591000000&usg=AOvVaw3-qg5MDtY7kD1HpR5jR2QY
>    Html:           https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html&source=gmail-imap&ust=1613767591000000&usg=AOvVaw05WK4GSEKcWjZzNhvb1p5d
>    Htmlized:       https://www.google.com/url?q=https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00&source=gmail-imap&ust=1613767591000000&usg=AOvVaw0qm45MWGbZf0zbBjZj3ggz
> 
> 
>    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.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613767591000000&usg=AOvVaw1Bfu9fJ2Fj_BZJ3H9yw7od