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

Torsten Lodderstedt <> Mon, 12 October 2020 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 257153A144A for <>; Mon, 12 Oct 2020 05:23:21 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6E_iu5Jrop26 for <>; Mon, 12 Oct 2020 05:23:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4CDE3A1436 for <>; Mon, 12 Oct 2020 05:23:17 -0700 (PDT)
Received: by with SMTP id 33so16649814edq.13 for <>; Mon, 12 Oct 2020 05:23:17 -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=miegZNS89ejq72/Sd5hT/F/Zipkgw334UQtYJcLERMM=; b=qn7NZLnTwaKj6qtSFSn/QHletZCoCjXTxGYfWOH8H+zVrrXwCoMQfPHtSvjxnEVqXE p9ktRnlPmNxs89vvqJ1I0m9BPjO+syT/tkE9/yAZJ9qZka6uuG09Zxr1CHpaf9NfJK+G 7aUA1DxrZ897Vn23BUp0y+4eC4tY5WhyxoERRbMWQffJ56Lj1MwraYZ9uFrpbjJ5qorj GDSNHvup0nV2kebZH552csirTwktlnBnzsrw945CSKR+8j17vjTpreWu2aKmL3uN/kH9 voY8v65ZSQZOqcHMZ0pSi631NAqYO9YvNkAg/qtMSmwB1kF563ToJKXiYCxDHECmyWrV T/8g==
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=miegZNS89ejq72/Sd5hT/F/Zipkgw334UQtYJcLERMM=; b=uf/xkWQjCcUy1iUrY8CtrbtGgXy0fmq5RgNZY1N9LiyHso2YCWySGW5kfFZGj5W758 QyMfAFjeAUeELRGyezNngOWdgphXoAsPHV1jpBm/HVl5bIqIVcoNTYlx2i9KAXqSEJ4p zTtmTi74neouoznsX4r19/MI7RXPFKCmqqfv/TM7y6ZPV3EXoPbiOZCBLXRj7aHSamZ/ 2AMLafcXJ6vFpCF5eKpkp9fKtX7JnmOiukkl5oswLHFxs6p1kdC0dlNAfA5EkKghu+4Q 6d0k8+vTTrDYMaZt/eyQgAqANKkUedt/ACVufztHq2LnTKOEuFco+V6CJd4vbKpibxeO oJKg==
X-Gm-Message-State: AOAM530XnyGHCb14ZOJTBYns7m8VkC5CzccqGlWO/AyQXwFzP9XrVYIK t6EqhTmgJho1KafGAz01JAlq2A==
X-Google-Smtp-Source: ABdhPJzSUCcHSXUx27ILvRD+KxfipgR3WfWZVuuWzuHcem0iYTcKx6jIzzJQ+/scViXzjzYHE9+4bA==
X-Received: by 2002:a50:ef12:: with SMTP id m18mr14045615eds.313.1602505396224; Mon, 12 Oct 2020 05:23:16 -0700 (PDT)
Received: from ?IPv6:2a01:598:9182:fe1c:8d43:995c:e49d:4e17? ([2a01:598:9182:fe1c:8d43:995c:e49d:4e17]) by with ESMTPSA id m6sm10462579ejb.85.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 05:23:15 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail-78464E6A-AFFB-4033-A06C-F4475F5968CF"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <>
Mime-Version: 1.0 (1.0)
Date: Mon, 12 Oct 2020 14:23:13 +0200
Message-Id: <>
References: <>
Cc: Torsten Lodderstedt <>, Jeff Craig <>,, OAuth WG <>
In-Reply-To: <>
To: David Waite <>
X-Mailer: iPhone Mail (18A393)
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: Mon, 12 Oct 2020 12:23:21 -0000

Out of curiosity: Have you seen this in practice? I’m asking since most/all refresh token implementations I have seen are handles. Just rotating for consistency makes especially the live of server based clients harder as they need to propagate such a change through the cluster.

> Am 12.10.2020 um 11:54 schrieb David Waite <>:
> An AS may decide refresh token rotation is useful for other reasons (such as if the token is an encrypted value and the AS cluster does key rotation), or may decide to rotate all tokens for consistency.
> Eventually best practices may indicate sender constrained tokens for public clients. At that point, refresh rotation may not be security practice but could still be something an AS does as part of its own design. And an AS may elect to do this often so that clients fail (and correct their logic) faster.
> -DW
>>> On Oct 12, 2020, at 03:15, Torsten Lodderstedt <> wrote:
>>>> Am 12.10.2020 um 09:04 schrieb Dave Tonge <>:
>>> Hi Neil
>>>  > refresh token rotation is better thought of as providing protection against insecure token storage on the client
>>> I agree with your reasoning - and that was more the intent of what I said. We've seen refresh token rotation used for confidential clients that have secure storage (i.e. are run in a data center not on a mobile device) and it has caused problems with zero additional security benefits. 
>> Those are good examples of why refresh token rotation should not be used if there are better ways available to protect refresh tokens from replay. Client authentication or sender constrained refresh tokens are the better choice.
> _______________________________________________
> OAuth mailing list