Re: [OAUTH-WG] Implementation questions around refresh token rotation

Sascha Preibisch <> Sat, 10 October 2020 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15BE73A08CF for <>; Sat, 10 Oct 2020 14:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tSNIV7ytt2Q7 for <>; Sat, 10 Oct 2020 14:16:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C05C3A08CD for <>; Sat, 10 Oct 2020 14:16:37 -0700 (PDT)
Received: by 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;; 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;; 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-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

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.


On Sat, 10 Oct 2020 at 13:42, David Waite <david=> 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