Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 16 May 2020 17:50 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 20FDF3A0A07 for <oauth@ietfa.amsl.com>; Sat, 16 May 2020 10:50:28 -0700 (PDT)
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 KzSgcHJteO_M for <oauth@ietfa.amsl.com>; Sat, 16 May 2020 10:50:26 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 728233A09FF for <oauth@ietf.org>; Sat, 16 May 2020 10:50:26 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id s8so7066486wrt.9 for <oauth@ietf.org>; Sat, 16 May 2020 10:50:26 -0700 (PDT)
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=G4w6x/Qa/p0JIObczuVRBGCMCZ1TIR0mowq4jschhRQ=; b=Usg3eWRKW1vEXgrZMoYOT0m1dVgigOAZEWoIJJ7vIzyn4MmSYF4EP4P2xlzGFlYpFf yTocGtHL3OVJbW1mIZpC3dZvC0faqx7bWlvYLpuM3qZEIvHvB1cwecbf3JMsjdrJvaJl 7b4+fulv+Rnrdy21qSXJb+nA3Pm/PkamEV0E+Do/fAzjEDuZuyGARWlS6H553w4rE+Ra /y4iqLFYA2BwaFqSqTlKXG+90NfD6TfF0SxkH7xIhkB76iukpaOodhnpBuxHtm+SNJ+M HP4KYlTYDzIbryQU7PsFUSGiwxbY8hvTH/1jejOOQ79xsXHwkU4239rGdd3PlKJBdXxl b3Bw==
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=G4w6x/Qa/p0JIObczuVRBGCMCZ1TIR0mowq4jschhRQ=; b=pm8AQHEYaYILvn5afGSLIj+NldntBOnOM5Nx0RJNRkcVneSa8oBie8h2AeQ1/Vrqtq JK8QyhIgZ0r79FKeEM64Fzga7ZrJk1kcxCvCOgBV0Ul4Rp6fZFatYhRO/YpcKbYocI80 urGdRxwRpA77XN+BpqsHQgALEmmgMVeqJTtYS0UGA6+uB+wK5Vev+7PbsI9WsZV8O8q/ 43JdIPr2UObEhCTUM63QJZeHkYnGxRRZXOObhjCPnLdmguWd+4or1HrUsO8ugRdpy1nK 1DFi0ePFthXjZ2zU8QGxq7H2bqj/QkDcrKIjbSQRejQUku7jJx8inlEPW+ZwPLZbePYx hqKA==
X-Gm-Message-State: AOAM5319PFYGh1DyD5bBJxHbvWKZjNZlXIrEyKTw/90ivF9dqP6IGhjU GbF6fcdpuHAOwMsTEy/oGeoGw4GIm0M=
X-Google-Smtp-Source: ABdhPJwewbDw6LnEGmjBEpPc2KBSPoLm1G4RRAzTPluRpa83GUUzPTtiuMAnKg6bktuEo1CH7/HpvA==
X-Received: by 2002:adf:e404:: with SMTP id g4mr10438946wrm.418.1589651424663; Sat, 16 May 2020 10:50:24 -0700 (PDT)
Received: from p200300eb8f301f5bf4b00d3ed436139b.dip0.t-ipconnect.de (p200300EB8F301F5BF4B00D3ED436139B.dip0.t-ipconnect.de. [2003:eb:8f30:1f5b:f4b0:d3e:d436:139b]) by smtp.gmail.com with ESMTPSA id o205sm8705941wmo.32.2020.05.16.10.50.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2020 10:50:24 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CA0EA922-5997-4BDE-8C47-D4EDBAC99B13@pragmaticwebsecurity.com>
Date: Sat, 16 May 2020 19:50:23 +0200
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A9DFEB7-9503-4034-9F33-4B2DC399CE4F@lodderstedt.net>
References: <CA0EA922-5997-4BDE-8C47-D4EDBAC99B13@pragmaticwebsecurity.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/t8e_eW7DtAb3ySn31AmPZGrk5zU>
Subject: Re: [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 17:50:28 -0000

Hi Philippe, 

> On 16. May 2020, at 17:08, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
> 
> 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.

I also see this as the main advantage of RTs.

I think scenario 3 can be made more difficult for the attacker by requiring user interaction. That’s ok since the normal case would be to refresh via RT and not via authorization flow, so the legit app shouldn’t be affected. 

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

I full agree with those advice. Handling security sensitive aspects of the app out of reach of the user (which might be an attacker) is a good idea. On the functional side, this also gives the app access to authentication and sender constrained access tokens via mTLS.

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

Section 4.12.2. of the Security BCP recommends refresh token revocation in case of logout. 

best regards,
Torsten. 

> 
> Any feedback on this train of thought is more than welcome.
> 
> Philippe
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth