IETF Logo Mail Archive

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

David Waite <david@alkaline-solutions.com> Sat, 10 October 2020 20:42 UTC

Return-Path: <david@alkaline-solutions.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 D1E393A07BD for <oauth@ietfa.amsl.com>; Sat, 10 Oct 2020 13:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 QWaozoFaVq6y for <oauth@ietfa.amsl.com>; Sat, 10 Oct 2020 13:41:59 -0700 (PDT)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899693A07B0 for <oauth@ietf.org>; Sat, 10 Oct 2020 13:41:59 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 56ECC20473D; Sat, 10 Oct 2020 20:41:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1602362517; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tVIUL5pJlkKBNlfa2qDUmQ2vdIMCMQeXy5QNh9W87CQ=; b=aNpIgRE7DaLPnXjPCzC9f0yb/nyDObKXFvvfz3eYuUNQwaD28dkb3d468EhIJGMu74Vd5d NqIqwYAWeJH5ugAR5sbfZ/YZuEpQp4ard6xXvo0F0fEne3XlHXA67zH8gnnT4RFLWuBxzu SHV8LWVW1kl4vQQMSwn3m2Vfl9psxvI=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
Date: Sat, 10 Oct 2020 14:41:54 -0600
Cc: OAuth WG <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF65E0F7-2BDF-4056-ADD5-5CD4D0036CF7@alkaline-solutions.com>
References: <CAGBSGjqFV9miQLJu4nZZcHy6vpnVcSA5FQdOBtKAQ1UCu8p6Jg@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dFEeAOTWapVMtPfxG3W7kb-1hRc>
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: Sat, 10 Oct 2020 20:42:01 -0000

On Oct 6, 2020, at 16:05, Aaron Parecki <aaron@parecki.com> 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

v2.23.0 | Report a Bug | By Email