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

Philippe De Ryck <philippe@pragmaticwebsecurity.com> Mon, 15 February 2021 10:27 UTC

Return-Path: <philippe@pragmaticwebsecurity.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 9335C3A10E6 for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2021 02:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 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, RCVD_IN_MSPIKE_H2=-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=pragmaticwebsecurity.com header.b=DxRGobm1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=czbAUBP7
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 MsEYZ1qdqLP4 for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2021 02:26:59 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127603A10E5 for <oauth@ietf.org>; Mon, 15 Feb 2021 02:26:58 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7236DCC5; Mon, 15 Feb 2021 05:26:57 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 15 Feb 2021 05:26:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=94CPxbDLWFyyyWRqVmmMugBdxCoJMEaQ/kEFXpUqvZU=; b=DxRGobm1FLu5 8X81kU95OQx9EeP063x2t8S9iy3sM8uUP+kDGdGEKgccfbMEXr31ZF0yQx4AZuVT w4SV5uSgwqWubnsulW4Tcz/5viR5weolVrT6pqGo6EGPKH4tlQISnUlPzBizCt10 Ga+Iseu00SxOAMnW71I0D7Tp1NgMrn4YOeL6BKRzNvTQH/BG1zCLVpAHawO+3HLY ijYea59NNdbbhPWZhBOkguFQwnd9wOArHVGnLGND8msYpj5wVEXrRseIv+Hni1p5 LpeTk26Fj+IdU5rmwH5kXsG8jpzPKkEcnMf22CfKQCx/ww6CgE5SZrEhp8M81zwX Pp7+S1cAsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=94CPxb DLWFyyyWRqVmmMugBdxCoJMEaQ/kEFXpUqvZU=; b=czbAUBP7f/BwdHFKgWSkvo gZKgUoEAKxUqCingxr2DzzBgoxgA8Iy4NhSdNTbLTQkxP6ZB7TbbB/BDUOvCgUgG 2yWbT1ykHEKKmv3Nw6mhCRVIKYviYp7S6/pPhYMNHT5oyy6jhqwj0J3Aa13skRvG jV63YD1K7DJbzAAPZRQZ4vehXmyloSYOHf3SYCP9x7rtsh/wGD9S/RtIVEviNj3o /4iPIFBombkIpkHNnWdhNUmBIpPRngO9Lq1jf8zJckyBNaCiRNzUE5yXjFSIoQvF fc+F7oCFrJkHt6LmWUoDrpKTCZ590qY6+oGy4OPQY5xcWUCeSNtwswomnRkNsZew ==
X-ME-Sender: <xms:cEwqYNuwWUBjyiaGBgwAApvaqKthLX4AJ5rIiFd46lhCDl9ioqxs8A> <xme:cEwqYL8umDnb-yzvCe_dDtRJBf4MINUSldtgylueDiMbb6Hw1jV-I2iv3J4RZwEI0 -6r7_IBc5AKwEco4w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieekgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepteelhfeghfevgfffjeefieeu geevffelleegtefgvdehudfhtdehvdethfdvgeeknecuffhomhgrihhnpehprhgrghhmrg htihgtfigvsghsvggtuhhrihhthidrtghomhenucfkphepkedurdduieegrdduvdelrdel heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphh hilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhm
X-ME-Proxy: <xmx:cEwqYJEY-ltkT12us19-3YS8FhhCxQAHcX-Iu9wuPkPuDhT3vaXPIw> <xmx:cEwqYCR78dqx0X_2KZB8ou_bnhWsuBtj90UUQI7lcWzBIb21O2YY_Q> <xmx:cEwqYPt8mu6x1CTsRSxE4oJNP5bj9ASMmliWM0mTkcaeXstwUAswjQ> <xmx:cUwqYCaeWw1C0JdGV_RxgZGDQbfDOIqT42Zc1t99DkyCNSb-O17_Ig>
Received: from [192.168.1.10] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 2503E108005F; Mon, 15 Feb 2021 05:26:56 -0500 (EST)
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Message-Id: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3064C9BD-7B09-498E-883D-8A8B3257AC07"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 15 Feb 2021 11:26:54 +0100
In-Reply-To: <E0F02703-4B45-4466-8A00-DB55D49891B4@forgerock.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth@ietf.org
To: Neil Madden <neil.madden@forgerock.com>
References: <43B559AA-D888-4E8D-8F82-4226676AC536@pragmaticwebsecurity.com> <E0F02703-4B45-4466-8A00-DB55D49891B4@forgerock.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eQbOByEmTXaxyzLiqglkz18i2pM>
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 10:27:01 -0000

> 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.

With the worker-based approach, the client is a public client that completes the code exchange without authentication. This allows an attacker to run an independent silent flow in an iframe within the legitimate application. This flow relies on the existing cookie-based session with the AS to obtain an AT and RT, independent of the tokens of the client application. A confidential client does not suffer from this problem (a stolen code cannot be exchanged without client authN, and when done through the BFF, the RT is not exposed). 

And as you state, there are other benefits as well.

Philipp

—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/