[OAUTH-WG] Implementation questions around refresh token rotation

Aaron Parecki <aaron@parecki.com> Tue, 06 October 2020 22:05 UTC

Return-Path: <aaron@parecki.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 129EF3A1507 for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 15:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=parecki.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 vgg1645ZQIoX for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 15:05:44 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 F10C83A09F0 for <oauth@ietf.org>; Tue, 6 Oct 2020 15:05:43 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id g7so88480iov.13 for <oauth@ietf.org>; Tue, 06 Oct 2020 15:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=b6cC0eKSpndxZwdQZS+zP0ktxLsQHhieie6xuJfUM0Q=; b=OZ0neKAYXVf5NQCt7UIJZEFbxXyggCB30eyFK36S7cXF//ngchLzAv74eDhwm5j40M gEf9m4DaXD5Oz2fRilvbWVOTJxvQ3k1K2vkT2nZ2JeL5kspn3DHPjt2BSYkRxivIfkTi Ay/YyKKw5KPF33tMvDxe5NlqMg2yl/cg3q8sQW/KDBq0obVFGHiRhtKCNXGx/qS0D/It g7uSXcIzzN6+WEdeMlsk/Q0nVJzgYqYBO+eDJf2KRJgppXfezN2BsneE7lA1OOrmVZyP BwoV/TGZ+JjKgZxl7RqNUX++1GgQ13N8Nurcp2xrNY1DWMsbP+cMTEBWrwFkM4/japFw WGOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b6cC0eKSpndxZwdQZS+zP0ktxLsQHhieie6xuJfUM0Q=; b=YDzJUtpqIhDmuY8eB2nd8KMmGKC6F37MzRVNjGm5HvT+pdpeKDK5CVGOmwR92CC6i+ u4rM90u7FwojrAA6X3xpnAcQl4OBgEjyaVVl2cyywhIOw1nADvxtGl4nkZCbuANzry6X s1L5kWFRcrhm/d77yfcnB0QSKm8pQ8EeyXtY28CELGQAU3FwroADg8deIcMuRqacMOnl hjLPhMGV24IkBg8Y6+s7ttJoJ456LHcFXNWuCHUy+yDuozNV5qnYa1cjTvBspbSdBl5n MOKuBhhYerhPOJ3H68v0sOgV55qsJlOLuUo7+STzVsTTtqGyU5KxjObzCRdF4KAZg7dq qOHA==
X-Gm-Message-State: AOAM532chpJPyO3SHk1e5jDx5iBl0cSUBx9LOmlR1oyU5HU66oDI0ITm 92FOr0hj8qZdEWBH2zT/y2BPK5H8sPc3Gg==
X-Google-Smtp-Source: ABdhPJxYKlpQmvAbot01WO6laIynnv8OyqchLJDaJmGSlawluKW78TsarYjDANPnMI0xSQ4t9/YWCA==
X-Received: by 2002:a05:6638:2412:: with SMTP id z18mr305891jat.56.1602021942577; Tue, 06 Oct 2020 15:05:42 -0700 (PDT)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id c18sm61307ild.35.2020.10.06.15.05.41 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 15:05:41 -0700 (PDT)
Received: by mail-io1-f47.google.com with SMTP id y13so159334iow.4 for <oauth@ietf.org>; Tue, 06 Oct 2020 15:05:41 -0700 (PDT)
X-Received: by 2002:a6b:fa0e:: with SMTP id p14mr2902902ioh.208.1602021941274; Tue, 06 Oct 2020 15:05:41 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Tue, 06 Oct 2020 15:05:30 -0700
X-Gmail-Original-Message-ID: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
Message-ID: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb6f2905b107cc9b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk>
Subject: [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 <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: Tue, 06 Oct 2020 22:05:46 -0000

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.

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
https://aaronparecki.com