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

Neil Madden <neil.madden@forgerock.com> Mon, 15 February 2021 11:15 UTC

Return-Path: <neil.madden@forgerock.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 0DEE83A117C for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2021 03:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=forgerock.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 T45xNFjEYNi8 for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 A56EA3A117B for <oauth@ietf.org>; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
Received: by mail-ej1-x62f.google.com with SMTP id g5so6998678ejt.2 for <oauth@ietf.org>; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=YKId1JNopQHqtp+Q1sr3DJtWJWyZ2JC17giu3utL45o=; b=X+LDC4Qhs+FsvWt5rmCUm/UpSnyvzaER5kmpogfIcP7dPv6boDpzo8OB4sfQAZG1Mj Ho9b0V5OSfM8M4kZZr6hHKpNidG8u4O6T1JXPnCQUSGV7+Vw4YSNKfrY3Kvaf2qgG+z/ VZ6RSJn5QgOV7rrVE5XCKRMNHpaW5N+I8YXoo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=YKId1JNopQHqtp+Q1sr3DJtWJWyZ2JC17giu3utL45o=; b=t5AeNWz30WPi5MGKuGDoMsjStJ9pXaqUGquCyFx764npObgZL3hjeQQSZqIQ7YGoyh NOMBDoVDvLvjlh6LQ+VPFt8hDlXLN4zwW/HhgPsLC0xiAHGcfVVGW8Ao5Og38rlRZJCE sV/joSNT0rUuqJ34nA9nx0j7Xc02seLjyt7dcdefKqLW0tNLzHwBA54a52qNs08SmuSY jJdOVe0ggRMnUbYZgDylTyczQ+OJr5V8h4ldbyw7lfyuIef3BIGgnx3HUQp6ukag+yTM GntkLLEo1AHnMUFaFvUKWzuIwILo83NgDpAOSQ6yepqX2r68N6bizDjeWwtZkl6Eaopp JDSA==
X-Gm-Message-State: AOAM532j3wxhqWwaQyIPDa0hG7vU/M74svu/5fXaV8JyqnZt1oRCw4Zp VI6N6aA9AaiqFHR3r8dTlf4KebdZsD3R4XcfO6oqPEeage7ZBmx6QC4Qb0iYh5XPwl6CGFu9/g= =
X-Google-Smtp-Source: ABdhPJydOmWD2e+03YahsgTPuN7VmSNHlBBjW7zvurTOOEvhPTui2WhWn90vDhTsUQ0fmRkXvkMunQ==
X-Received: by 2002:a17:906:e4f:: with SMTP id q15mr14973476eji.216.1613387749012; Mon, 15 Feb 2021 03:15:49 -0800 (PST)
Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id 35sm9910413edp.85.2021.02.15.03.15.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Feb 2021 03:15:48 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Feb 2021 11:15:47 +0000
Message-Id: <17812F95-7350-4595-9867-EF9D9452CC07@forgerock.com>
References: <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth@ietf.org
In-Reply-To: <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
X-Mailer: iPhone Mail (18C66)
Content-Type: multipart/alternative; boundary="Apple-Mail-1812512E-1133-4B1D-9DB6-3694DF6716E5"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/e-RIJ4AHQSQAV1c5yJgUBP1v7w0>
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: Mon, 15 Feb 2021 11:15:53 -0000

Yes, I’ve argued against this distinction for DPoP too. Since the first days of HttpOnly attackers learnt to proxy requests through the browser (as you know of course). This is not only to bypass the restrictions but it’s also just much better for the attacker because it hides their traffic and origin. People are online all the time now, so this is at best a mild inconvenience. 

— Neil

> On 15 Feb 2021, at 11:09, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
> 
> 
>> 
>>> On 15 Feb 2021, at 11:50, Neil Madden <neil.madden@forgerock.com> wrote:
>>> 
>>>> On 15 Feb 2021, at 10:26, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
>>> 
>>>>> On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>> 
>>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
>>>>>> 
>>>>> [...]
>>>>> 
>>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF only adds a single security benefit: an attacker is no longer able to run a silent flow to obtain a fresh set of tokens (since the client is now a confidential client). 
>>>> 
>>>> But they can just call the bff-token endpoint to do the same. If there is a security advantage, IMO it is as a defence in depth against open redirects, unicode normalisation attacks (ie not validating the redirect_uri correctly at the AS), etc. 
>>> 
>>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose the (short-lived) AT.
>> 
>> I don’t think this distinction matters at all from a security point of view. It’s the AT that attackers are after - why bother with a RT if I can just call the bff-token endpoint to get a new AT every time?
> 
> Getting an AT from the BFF (or a worker) is an “online” attack, which only works as long as the application/malicious code is loaded in the browser of the user. 
> 
> Stealing a working refresh token (e.g., with a silent flow) is an “offline” attack, which gives long-term access (lifetime of the RT), independent of the state of the application in the user’s browser.
> 
> There is a clear distinction, but whether that matters is a different discussion. It depends on how the application used, and how token lifetimes are configured. FWIW, the DPoP threat model makes the same distinction ("Stolen token (XSS)” vs “XSS (Victim is online)”) here: https://danielfett.de/2020/05/04/dpop-attacker-model/
> 
> Philippe
>  
> 

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