[OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation
Philippe De Ryck <philippe@pragmaticwebsecurity.com> Sat, 16 May 2020 15:08 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 9C06B3A07E0
for <oauth@ietfa.amsl.com>; Sat, 16 May 2020 08:08:53 -0700 (PDT)
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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lCi6aHFa;
dkim=pass (2048-bit key) header.d=messagingengine.com
header.b=RmeIZmlt
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 SAUxBYZSMZI6 for <oauth@ietfa.amsl.com>;
Sat, 16 May 2020 08:08:52 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
[64.147.123.20])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 57EB43A07C2
for <oauth@ietf.org>; Sat, 16 May 2020 08:08:52 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.west.internal (Postfix) with ESMTP id 057795D1
for <oauth@ietf.org>; Sat, 16 May 2020 11:08:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Sat, 16 May 2020 11:08:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
pragmaticwebsecurity.com; h=from:content-type
:content-transfer-encoding:mime-version:subject:message-id:date
:to; s=fm1; bh=h4y3MdgysriQ1mvK/tdcT5fhycgdLYB0Dox/nCzUwbk=; b=l
Ci6aHFaU3G1SD83EmKOMNDhSTGD6oKP2TkwnWQu1bE7+U6eeOlooRRLLvwe+pu0o
68cA8/xHy7rjgosx8r9AbydvPFlFxPfqGC6ebScMzLdih//4pxyRZWg4gXT8EwL3
wBgdWb2GmNHKDpvFeiinnzrxGYJxDwDEMjOp4NagE80d/ewgOJSIlZlghpKySdFS
HBbEqeCcMWTXTYmJcPh0rxUoUnquuCJmM/0GrsKmZNlaKjXXtRFw1dlEiaN35pFl
M9Qib5xlZUSw31xt2bRAwjziTlkvUgY4nqj0+fn5CosXSti86ukKqDKbwt2zfGtn
IMWKoZ3i3+K8TdqRVVFJw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:message-id:mime-version:subject:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=h4y3Md
gysriQ1mvK/tdcT5fhycgdLYB0Dox/nCzUwbk=; b=RmeIZmlt/G3Ij0S0J2k0uL
9mF8rbNLtaqlWlMXQog/7NfLNuJl+dISMChDrPcMFZi1hG1IaWUJB820XkHeoPlB
GNOLsECjzKKO29yCDuPbHoV6665gh7YhbQG56PykZDQ2udOHWyOGHMi8uccufgwC
/cLQ4kdm7ZWoqgX4l+YdxhfopZenoBSQXUzA94xazlD8QIr8a1czPPAhqRfu4iX/
BihTvZdv5UzCFXKxTCrLoy63G9XPfcW7OE3HFCBm672h5DAkej51E91Gh2NFcQv0
5CRxUjrZChAziTxorHjzL8+1nkrWo2nvnVTkdEDSoNi61M41g2foupbgODVT+yEw
==
X-ME-Sender: <xms:AgLAXnN0gWGA3lgoIWIcphThT-ABAaIk7ik5VOG6OqVUVVWuC6E63w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddttddgkeegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd
hhtddvnecuhfhrohhmpefrhhhilhhiphhpvgcuffgvucfthigtkhcuoehphhhilhhiphhp
vgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhmqeenucggtffrrghtth
gvrhhnpeehtdefveffgfeiheehkeelhfffheethefhffffuefhgfdttdehkeekgeelhfev
udenucfkphepkedurdduieegrdduvdelrdelheenucevlhhushhtvghrufhiiigvpedtne
curfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgif
vggsshgvtghurhhithihrdgtohhm
X-ME-Proxy: <xmx:AgLAXh8DuC4tTljUCLlvhhqzUwDENRxLOG1xM0Vx8j_om-LOfC7bdA>
<xmx:AgLAXmSGG_GYOivc9TjyfdoYuTUJaIyqtXdHftfFo0NhkASkC8EnbA>
<xmx:AgLAXrt8iUSLOPgvsesywoDeuSuZi2dpXctiubKFc1JVVF9Z77HW_g>
<xmx:AgLAXi9Yu_oLPXQw1QQ0VeoqtXdLK8zumqBtX62uPnuDvEsA0vFSbA>
Received: from philippes-mbp-2.localdomain (d51a4815f.access.telenet.be
[81.164.129.95])
by mail.messagingengine.com (Postfix) with ESMTPA id B59E9328005A
for <oauth@ietf.org>; Sat, 16 May 2020 11:08:49 -0400 (EDT)
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <CA0EA922-5997-4BDE-8C47-D4EDBAC99B13@pragmaticwebsecurity.com>
Date: Sat, 16 May 2020 17:08:48 +0200
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/s68mcQCC1NNe_Y2Q9Qu6x0VuLrI>
Subject: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of
refresh token rotation
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: Sat, 16 May 2020 15:08:54 -0000
Hi all, I am working on formulating developer guidelines on using Refresh Token Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". The protection offered by RTR kicks in the moment a refresh token is used twice, so the assumption is that the attacker has the ability to steal tokens from the client. In general, this means the attacker has malicious code running in the application (e.g., XSS, remote JS inclusion, ...). Within these constraints, I can think of a couple of malicious payloads that sidestep the protection offered by RTR: 1. Stealing access tokens in an online XSS attack 2. Stealing refresh tokens, but waiting to use the latest until the original client is no longer active 3. Running a silent authentication flow in an iframe to obtain a new and unrelated AT and RT, and use that until it expires Scenario 1 is straightforward in most applications, but the attack requires the vulnerable application to remain online. Scenario 2 might be difficult if the RT is kept out of reach from the main application (e.g. in a worker thread). Scenario 3 is most dangerous, but also a bit tricky to implement as the payload needs to make sure the application's code does not interfere (however, the browser's Same-Origin Policy will not intervene). The specifics depend on the concrete implementation, but all three attacks are technically feasible. With these attacks in mind, it seems that the use of the Authorization Code flow with RTR does not really add much improvement for security, if other best practices are followed (e.g., using HTTPS). RTR does a lot for usability and handling third-party cookie blocking scenarios though. In this context, my advice to developers is to avoid handling tokens in the browser in security-sensitive scenarios. A Backend-for-frontend pattern gives a server-side component control over tokens, along with the ability to implement additional security measures. Additionally, is there any official recommendation to link the validity of a refresh token to the lifetime of the user's session with the Authorization Server? Having that property gives RTR similar security properties as the silent renew scenario. Any feedback on this train of thought is more than welcome. Philippe
- [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On … Philippe De Ryck
- Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps -… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps -… Philippe De Ryck
- Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps -… Vittorio Bertocci