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

Neil Madden <> Wed, 07 October 2020 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D66BD3A119C for <>; Wed, 7 Oct 2020 00:20:48 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fCZOiTM7hTDA for <>; Wed, 7 Oct 2020 00:20:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E00E73A0DEF for <>; Wed, 7 Oct 2020 00:20:45 -0700 (PDT)
Received: by with SMTP id g12so885750wrp.10 for <>; Wed, 07 Oct 2020 00:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=dTQaoCND23ZY11Kj/XRkGi/s+Q15SIZjppHzRDl6GKk=; b=Hfn/7nFl4mj9cdCuWl3X24GrFzkKOvwV120vrGN+SabjxB3HbVY7jXSxIuQ3OayqaR CtKNKlMR8H086n5+DTszQfNng2+NidKNJvKOGYUksm6d3OnEOC6KuDagoSuiGWJLFzIg ZpkCeftN/2rDRli4OMtCFlya/yNYcWXi8oXqY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=dTQaoCND23ZY11Kj/XRkGi/s+Q15SIZjppHzRDl6GKk=; b=FfVX3vnxf83HBRiAMBEwtwPvf7Nbr/cCfHn9mF5rUN9DB+ttRTOp269TpRzwWnVBOD sOWfeO2lJzfgKGhidcMPKOXqPx9OHNH4471f8chCQXMfrhbt0xcwndqyQvQpaiTURD5I 41r2ntXHcJk8pKwAkokuZRKp+kcswyoLICVeI+EeDxPK37NFct/W/PACAbneCc3549on xfyzWCmxMTeR1ttY6rfrunzjf8M9RQCxAALO9ec356sG3j2ITXL+WuHZ5M7pHP4/Jyp0 m3qOJ458/a8vX+GH+cx99yxI+KSQjS37tmagorZfYOYYnbu5cWFqsDI/KVM6hEkyGk2t LDkA==
X-Gm-Message-State: AOAM5309hhduybmAopG0cd4Dnc338Ywml41oRP1vu/0IpQIHqf0x/l69 4GAlGZ/nF/0RHHuQ3ddFAoZiTxfkbaP2Kt1ED1TYy7h3BZKuNKHDxxaf/trR+XlEtj6yf1PFHBd p/GVRg0FcjLGX516lZv0UmbWOSjlWWh7BJqbfso7voS9V8agAhH0F3hphL/nctl/WAqQkqiA=
X-Google-Smtp-Source: ABdhPJwdGjvbj0wIm3uPO6ZzaYyT9jzIuF0tFEVPcLicgcWuDSu0nON3V+SeQBCXvsNDvEb58x+Ihw==
X-Received: by 2002:adf:fbc5:: with SMTP id d5mr1785613wrs.232.1602055243216; Wed, 07 Oct 2020 00:20:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o129sm1429230wmb.25.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 00:20:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-94A1AFC1-0609-438F-B835-EAFBD79FE40D"
Content-Transfer-Encoding: 7bit
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Wed, 07 Oct 2020 08:20:41 +0100
Message-Id: <>
References: <>
Cc: OAuth WG <>
In-Reply-To: <>
To: Aaron Parecki <>
X-Mailer: iPhone Mail (17H35)
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: Wed, 07 Oct 2020 07:20:49 -0000

> On 6 Oct 2020, at 23:05, Aaron Parecki <> wrote:
> Hi all, I have a couple questions for those of you who have implemented refresh token rotation...
> Have you included the option of a grace period on refresh token use, allowing multiple uses within some time window? I'm wondering because a grace period where a refresh token may be used more than once would work around the problem that has been brought up, of a mobile app accidentally using a refresh token more than once during normal operation because different threads are unable to coordinate between themselves. 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.

Right. We’ve avoided adding a grace period for this reason. An attacker in a position to steal a refresh token is also presumably in a position to see when the legitimate client uses it and then sneak in just afterwards within the grace period. You could maybe only allow grace period refreshes from the same IP address but I’m not sure that would always hold in the flaky mobile network scenarios (eg refresh fails on 2G due to disconnect then client switches to Wifi hotspot and retries). 

> If you have implemented a grace period, then how do you handle expiring the additional refresh tokens that have been granted? For example, if RT "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what happens if "R1.2" is then later used? Would you invalidate "R1.1" at that point? If so, why, and if not, why not?
> It would be most interesting to hear practical experience from people who have already built refresh token rotation into a system.
> Thanks!
> ---
> Aaron Parecki
> _______________________________________________
> OAuth mailing list