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

Dominick Baier <dbaier@leastprivilege.com> Thu, 18 February 2021 07:43 UTC

Return-Path: <dbaier@leastprivilege.com>
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 E19D33A0CE5 for <oauth@ietfa.amsl.com>; Wed, 17 Feb 2021 23:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.com
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 sq5aKeAeKSbc for <oauth@ietfa.amsl.com>; Wed, 17 Feb 2021 23:43:10 -0800 (PST)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 25B0A3A0CE8 for <oauth@ietf.org>; Wed, 17 Feb 2021 23:43:09 -0800 (PST)
Received: by mail-il1-x12e.google.com with SMTP id q5so674557ilc.10 for <oauth@ietf.org>; Wed, 17 Feb 2021 23:43:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YU99IZyoNhkclwskPBnLojx3BKYRVzRymcn7vZc75fc=; b=c7wGVntv8URbQxI1YoySNPIrsg1IyEiwn827XUySfch2QSqclexbw1+air417TNNJq ySvxz/pIugmDxIECn8c3xIe01GxHHtlfB0/595Mq25RfmwTTFeES8PFdBjt8LV7eonqR kKpvFx6vTxXzAge8cLMTpo754CCWRqhJ+o0GFWnSnPkUYmT0aHgaKYEnOPJYZXRbTl/4 WVW5XAHuX33Dsu90RkCGuY55OwFwo2/5pCStXkrwE+ircB8EWQdv942AwBqMFPI+jPha z2CPBIcNjsMeKus5E/7NyWlLZToZS2i2imSydg0uzLNR5BixIayYhOFd/Oe+9giZ1Ueh smGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YU99IZyoNhkclwskPBnLojx3BKYRVzRymcn7vZc75fc=; b=mvrcU1mVrUN6GD1KoHVUZeQ0jFc3wZMTZfvHW9oAGIO8rRNDkp9P13aBGeKxUUDS+p grw1hj2vTjSbcRYl2sYIz+pbTaOjKH9a1O9VI+ZhKiTfmxbs05ACjy5H3ODC5CJnG3BH FPUFtCeWDkxGRIWu2ExDvunhmRt5a6/wVtwiyeoWi+8Mtlen6BOq3eSzafXhooFm4Aij QEDYTNkLQx8EwPjZ6berxilOWvFfkGuKcbnwVbPzisKkW3ggY2cBjiGiMDR42uo0DCgX TgNGXUJqVITtPSsOUnfC//e5nyH4R9BBg4bKGX/t8Hvxe9lmlCW/pRvMcHpZbmSRHjyH XTmA==
X-Gm-Message-State: AOAM531HlfiRs7iBmLzKRKy+QQ7oj3uaJFQQBvSrshThUqxGoEIzuqAP /rspD3JgnbkQcZSCBZjYK0DXQSU/SufS30/4abKN
X-Google-Smtp-Source: ABdhPJzVb6PhjbqKLkwX/p3RL5gIAbs38Z+vddO63opSoNr8oeBYZU2bSxNQEsvOVq2UWad5hLXvRY92pN3axCB/t5k=
X-Received: by 2002:a92:b00d:: with SMTP id x13mr2676145ilh.128.1613634189076; Wed, 17 Feb 2021 23:43:09 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 23:43:08 -0800
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <98E38875-F022-419C-87FA-1218B4A16660@forgerock.com>
References: <CAO7Ng+s+wpvCtaE+1K+C30LmN1osBoqEUYWBbkDgaoWFg9sJeg@mail.gmail.com> <98E38875-F022-419C-87FA-1218B4A16660@forgerock.com>
MIME-Version: 1.0
Date: Wed, 17 Feb 2021 23:43:08 -0800
Message-ID: <CAO7Ng+vf=LB68FfK4M1dg-BffO47k+T=XW8MGVT+T-c_Pb8Y_g@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a3444605bb977c9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QWpvZbZgHCPKfq-u792vWr9ErtA>
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: Thu, 18 Feb 2021 07:43:13 -0000

No. But they are CSRF protected (either SameSite or anti-forgery) and
HttpOnly.

———
Dominick Baier

On 17. February 2021 at 21:08:37, Neil Madden (neil.madden@forgerock.com)
wrote:

Do you eliminate the cookies too?

On 17 Feb 2021, at 19:50, Dominick Baier <dbaier@leastprivilege.com> wrote:


Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.

———
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote:

While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier <dbaier@leastprivilege.com>
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.bertocci@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier <dbaier@leastprivilege.com>
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt <
> torsten@lodderstedt.net>
> *Cc: *Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>