From nobody Sat Oct 10 14:16:40 2020 Return-Path: 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 15BE73A08CF for ; Sat, 10 Oct 2020 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 tSNIV7ytt2Q7 for ; Sat, 10 Oct 2020 14:16:37 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 0C05C3A08CD for ; Sat, 10 Oct 2020 14:16:37 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id h20so13031472lji.9 for ; Sat, 10 Oct 2020 14:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Dhy7lVdq9vVfjAAk7VsjD0FalzfFf3cceovgCMacigM=; b=ZklasIT54KBF9RQoJ90D58GahNuhKOMCRc8EZ1w8EQyZVQTCrV7zB8lc6dRgXdg9qG MSo84FC61eZtfztFzoPTYtj8NJOco7sQb41OAjdjsp9XvyLfMIiHrrrpbO00OuWBaxDe mDjSKL7f3HGCGLrtuDzHgfegpM+AhMI4lom+IekEDYkkPVv6REIZc6SkbEJ4B26Uvfon awS61uigcpm9iHQYQ+aCcxM6QT9Gh19B1dYgE05hLQNLx1xJP+EVIoO58NENhA/PnB0f HqGXh2eL82AO+Fi8SAkyjfyiWn8ALut6ENbzkePgdVc8rPGZ5lxxd/NSpcsKbHK0XWrX TQkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Dhy7lVdq9vVfjAAk7VsjD0FalzfFf3cceovgCMacigM=; b=X+4eE43dVGEITP2eaF8p0Enhb32lB5/56aBrTZ8bxSiQKAv48HAJrZ6fJmQK2AxodY jn3337V/daG/mktrVy/OVznZ1sAgjzrcVPtm/aHBB0Uw3ZW+EbgLXgI6H+V78eI7Uc4U hg79ef17dmfIKAuQUh7wYCWH5MwnehMo0WBGFo6d4dZw9XMneFqA7LIjGsXebsKDoV6Y YstOwfycg0hkv5hwO/e0+QXsDL7d6N8JaW7abuvTZ48Q95XtCGqDLSpQ8MIYDQ086gKg D5ZJhfKqFai0DL0LH6hNveg8TWvIj1/9E0V0dLjqaik5S2aV8nM41TvxJnC2Mm8quNTl LZnw== X-Gm-Message-State: AOAM5309xDKSfAtOXV/zXLSxS1fT6N/Y5/QyJloaHjFtT73vTzz5ozZd p/DyeLh29kZ5+Px4ACGgFjHi1XQHZDLEpwT59nFNxqtKprk= X-Google-Smtp-Source: ABdhPJw6HNcZB5p+i7w0KcdzPDy05RjA3Ot6dh8bryZBY18EpYLQl5le+wvy1HCmD3NtDvq/NEPp5DkbOhBltGxLqtk= X-Received: by 2002:a2e:a177:: with SMTP id u23mr7196069ljl.104.1602364595021; Sat, 10 Oct 2020 14:16:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sascha Preibisch Date: Sat, 10 Oct 2020 14:16:23 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000007cad6d05b15794e6" Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 21:16:39 -0000 --0000000000007cad6d05b15794e6 Content-Type: text/plain; charset="UTF-8" In the past, customers brought to our attention that some clients were not able to receive a new refresh_token and use it right away. For that use case we added a different type of rotation. The new refresh_token was exactly the same as the given one. Except that it had a new expiration date, lifetime and such. It was usually tight to exactly one scope valid scope value. Since customers were able to configure this behaviour for specific clients, they used this feature for single or a limited number of use cases. Other than that, a used refresh_token became invalid once it was used with no overlap. Regards, Sascha On Sat, 10 Oct 2020 at 13:42, David Waite wrote: > On Oct 6, 2020, at 16:05, Aaron Parecki wrote: > > However that also kind of defeats the purpose since attacks within that > grace period would be hard to detect. I'm looking for an idea of where > people have landed on that issue in practice. > > This is effectively a race condition, and a grace period hides your > ability to detect the race. Because of the race condition is no guarantee > that the second refresh token is the one that is retained, the client could > still fail once it needs its next access token. > > Instead, an ideal system would allow you to make a security exception and > turn off rotation, possibly only until the client revises their logic. > > -DW > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007cad6d05b15794e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the past, customers brought to=C2=A0our=C2=A0attention = that some clients were not able to receive a new refresh_token and use it r= ight away. For that use case we added a different=C2=A0type of rotation. Th= e new refresh_token was exactly the same as the given one. Except that it h= ad a new expiration date, lifetime and such. It was usually tight to exactl= y one scope valid scope value.
Since customers were able to configure t= his behaviour for specific clients, they used this feature for single or a = limited=C2=A0number of use cases.
Other than that, a used refresh= _token became invalid once it was used with no overlap.

Regards,
Sascha

<= div dir=3D"ltr" class=3D"gmail_attr">On Sat, 10 Oct 2020 at 13:42, David Wa= ite <david=3D= 40alkaline-solutions.com@dmarc.ietf.org> wrote:
On Oct 6, 2020, at 16:05, Aaron Parecki <aaron@parecki.com> wrote:
> However that also kind of defeats the purpose since attacks within tha= t grace period would be hard to detect. I'm looking for an idea of wher= e people have landed on that issue in practice.

This is effectively a race condition, and a grace period hides your ability= to detect the race. Because of the race condition is no guarantee that the= second refresh token is the one that is retained, the client could still f= ail once it needs its next access token.

Instead, an ideal system would allow you to make a security exception and t= urn off rotation, possibly only until the client revises their logic.

-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000007cad6d05b15794e6--