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

vittorio.bertocci@auth0.com Tue, 06 October 2020 22:28 UTC

Return-Path: <vittorio.bertocci@auth0.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 77FF73A151C for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 15:28:28 -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=auth0.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 M85ELC0HTcXF for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 15:28:26 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 D27843A0FC0 for <oauth@ietf.org>; Tue, 6 Oct 2020 15:28:26 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id h2so1941595pll.11 for <oauth@ietf.org>; Tue, 06 Oct 2020 15:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=TLPz8Y+P9P99g8nDCCz7MkvO6V8hyUhfoEy7nUOAT6o=; b=rNTmoC3KQu2ohkpOwtGMqwYo+zPRm8Pc/6ELEJ5Mnapmw2fxlm0MNIuoBuG+1qreO+ Ng7C9Q0nL/5Ht9CELG8bYHkY0cwkeAQYK900y8nLEF6RGSLCGDvg9s3QcfBhjMSWijFb Ny8tujQW+PRvCjjwafxLRcnUVhFyab5/An88zgEjETLrdlqEjsZk/8yLZqUIIcbwxq8i fzxx4pKzm5K8gaArDTwRsyMSzOs/hibng8aBRZ3RJwXAQBtTXZgv+0SnOLBkR9Z5bWNu pkcZzWj8PQgv3JZKp5GyNPKXupU616AMZ7xEzdu/WNCt9sHC2wyAW1S7lPmWmy28ZJOZ EHKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=TLPz8Y+P9P99g8nDCCz7MkvO6V8hyUhfoEy7nUOAT6o=; b=KKHg0y4aFIQFFMglO7qZaXmt5MZu7YfY4OM5uJhvJo7E23369eEjeosPOnsQEmdMMi CkEsQndsA+sDHRoVuD+79CtIV2nDia2eysTIMQloKWCDo+9vfZGYShY0cffgTRyfVl4M E7KeJf7IjDpWR6RcECEM8UnLcH12dSUXy1k1Qw7OFGwUIqdSSCQgaM1qnx/JJ+XjjCKM SaMWSjgfz2XiFMIXCWt1b34YQL8n5UYEPOetSAzXtt/qiJnpcCoLxLi9CDKEYf8eRTh0 660e+IfL9KxIalt/OToCq7FiqWpAVKYtF3gVPBGdm6UbHEv2vIhdgx2GI8mmXrNJgK0F cliA==
X-Gm-Message-State: AOAM5339m8k8QGWre7TRtu8We5tEySgUUMGVarogs57EVXuu+9hVHSLE WTibE7x0cXDva8l9WIi3O55y1V32Q6Adxulw
X-Google-Smtp-Source: ABdhPJzFUsQEvdgcdjFmRToNHmZrBUI6pETjHwQVKEsbyt7AYmAeusBiuKJxau3VgHb++KdCjUQS8Q==
X-Received: by 2002:a17:90a:17ad:: with SMTP id q42mr269386pja.36.1602023305859; Tue, 06 Oct 2020 15:28:25 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id g3sm36130pjl.6.2020.10.06.15.28.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 15:28:25 -0700 (PDT)
From: <vittorio.bertocci@auth0.com>
To: "'Aaron Parecki'" <aaron@parecki.com>, "'OAuth WG'" <oauth@ietf.org>
References: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
In-Reply-To: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
Date: Tue, 6 Oct 2020 15:28:25 -0700
Message-ID: <067801d69c30$02119bc0$0634d340$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0679_01D69BF5.55B42350"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFWoIr2EjR7EjLptonet55CHSVES6qLGtTA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/l_fM8rvHZKxOr9BdyvcHjRwpLgY>
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 <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:28:29 -0000

Hey Aaron,

Auth0 does offer a configurable grace period, during which the “preceding” token can be reused. 

I am not 100% sure what we do in the exact scenario you described, and I will double check for you, but here’s my intuition.

 

The operation redeem(RT_n) should result in AT, RT_n+1. The grace period just extends the time in which the operation can occur, but every operation should be idempotent. All repeats of that operation within the grace period should have the same result, which means that every resulting RT is a representative of the RT_n+1 class, hence all valid at the same time. After the grace period elapses, RT_n is invalid, and that’s it.

So, in your example I would consider RT1.1 and RT1.2 as equivalent, as they are both representatives of the RT_n+1 equivalence class.

 

It would be very hard to do otherwise, given that network operations aren’t guaranteed to be concluded in the order they were executed without semaphores, and above all the network failures the grace period is designed to handle can apply to any of the requests, regardless of the order.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Tuesday, October 6, 2020 3:06 PM
To: OAuth WG <oauth@ietf.org>
Subject: [OAUTH-WG] Implementation questions around refresh token rotation

 

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