[OAUTH-WG] Re: Refresh Token Rotation

Aaron Parecki <aaron@parecki.com> Fri, 02 August 2024 13:17 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 5AF3FC14CE4A for <oauth@ietfa.amsl.com>; Fri, 2 Aug 2024 06:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElkV4vSgyV1m for <oauth@ietfa.amsl.com>; Fri, 2 Aug 2024 06:17:41 -0700 (PDT)
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E1EC15170B for <oauth@ietf.org>; Fri, 2 Aug 2024 06:17:41 -0700 (PDT)
Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2642cfb2f6aso5197405fac.2 for <oauth@ietf.org>; Fri, 02 Aug 2024 06:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; t=1722604660; x=1723209460; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BPi/kijN/yHTys5uKaJjVpgAltsafqoeofM02eSFzEs=; b=f8yzHiohMxVNrU38r/0qOykfbmaVvN+VKGetNTzjzceLbipH7G8VucxyS1e7DH4Wwf f9YBOlTpay62ZY85wRpytIXya+Ef6Ch3CIP880NQ+Q/bno/Y+mFg1Sb2dCArwg5qp1y/ DISsPvpmW/12ntO+/gkIf4TC7lW5P7vDjN3rWfU8KGcqtfc0MwzHzykNKY9MEN/8/tHH ksrDA6nrG5Tlkg9seFKgrIYRT/Jb3AFDiexexdXsdgn84QFVBUujRLERfHSBxLvM8Www OYwhc4QhItnWkasPpVbDwh9q6/YPm16Xh8chw7/TYBet+V/FOafZY/2BQ3nNTXMmpfJa 8vwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722604660; x=1723209460; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BPi/kijN/yHTys5uKaJjVpgAltsafqoeofM02eSFzEs=; b=bZFwwj6219RWnmxg8Sx8mN62VBs97j6CfZic4o42nuwNn/3GtCgXlFngPa+4bcr0D4 S/6s5IF16GHUrpefds/InqoFIwPHUjPSQu/SOZrWztEk6JUwePrTls0MkB3Iz8Z3P+pV Uy6cZI40OFR1J0cWpssZCq3evtpdVgPKJgDbRhS6sCmnvysQswbRBiifaA+XShMEypvn OZMZHBPHUWGTgAYob9zGE1ZkFFmvH9Vc5v9GdJEJu92462+QV6HgkBvTI0bX7IdDesf9 VA0pS9R2u1PmY1FsUAsW1OklFthwjaDIwoWiczwg6Ra+ybPisx21bTE5vUEPpr4xq5ho bOfQ==
X-Forwarded-Encrypted: i=1; AJvYcCUCJFaK3lnsEb5VmgEBanG1+E9d4X1qwlxbcWZ3mY2wTA+wZlHDvmWn1e0iCoHY9tTu+hHQViHMFwUjbMQ1Jg==
X-Gm-Message-State: AOJu0YxI+d7482P6ybtfTwjoMsvVpcCeO5vO9MbCsHfZZzhZ3MaeWm5b qhFgXQV/XxPxTNbxVhj9oZhpmBz8Bc/jwj8jmuGEmuRWVrlkYMN4ltNxDisVrNvdApvijp5abQA =
X-Google-Smtp-Source: AGHT+IFPQ+qQD0rjnbiS+8qcO77KqXjaMiFvh6f65AhHRKil21NqLy1edx35r6ZS/FQw5y9tWkNC3w==
X-Received: by 2002:a05:6870:b015:b0:260:eb3a:1bc with SMTP id 586e51a60fabf-26891ed88femr4484387fac.41.1722604660035; Fri, 02 Aug 2024 06:17:40 -0700 (PDT)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-70a31d9df69sm462309a34.13.2024.08.02.06.17.39 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Aug 2024 06:17:39 -0700 (PDT)
Received: by mail-oi1-f182.google.com with SMTP id 5614622812f47-3d9e13ef8edso5345152b6e.2 for <oauth@ietf.org>; Fri, 02 Aug 2024 06:17:39 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCU5wHGe5rXTxk4yii4kQP5HIlIdPM6MvEKaZgcGmk+SrGF+UhQP8qfcfEeivRy85LZm7w4zbED4/2/dH3G9bQ==
X-Received: by 2002:a05:6808:1206:b0:3da:4c28:6697 with SMTP id 5614622812f47-3db5582e23dmr3734315b6e.38.1722604658938; Fri, 02 Aug 2024 06:17:38 -0700 (PDT)
MIME-Version: 1.0
References: <CADU05gP9Zn_18bsmmiUgLNVsDGN9HEurJvF30jCbT5-nx4ycMg@mail.gmail.com> <CAJot-L2qJBRfgc2CpnokjP2Dk8iwJ9L7UDBuj+j6a+D6JG99oQ@mail.gmail.com> <CADU05gMuKgptBKVqQQoJY-HiYizbCAdy+eV3eYo8QAUmtzn7Mg@mail.gmail.com> <LV8PR01MB86774D0F4A183E9E92B31044BDB32@LV8PR01MB8677.prod.exchangelabs.com>
In-Reply-To: <LV8PR01MB86774D0F4A183E9E92B31044BDB32@LV8PR01MB8677.prod.exchangelabs.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 02 Aug 2024 06:17:27 -0700
X-Gmail-Original-Message-ID: <CAGBSGjp_iGvCYMdJhHj280FX2TudKyo=YD2zW9WrV3Bkd8ba+A@mail.gmail.com>
Message-ID: <CAGBSGjp_iGvCYMdJhHj280FX2TudKyo=YD2zW9WrV3Bkd8ba+A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000c8e3c2061eb326b2"
Message-ID-Hash: WFTD3PFA56XBFXO62SS66XKUYYD5QJNJ
X-Message-ID-Hash: WFTD3PFA56XBFXO62SS66XKUYYD5QJNJ
X-MailFrom: aaron@parecki.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Indeewari Wijesiri <indeewarii@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Refresh Token Rotation
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/czS6NdtRu0h8T-FRWpfb-BYpIwc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

In other words, refresh token rotation is not specific to the refresh token
grant, it applies to the use of any refresh token regardless of how it's
obtained.

Aaron


On Fri, Aug 2, 2024 at 6:08 AM Justin Richer <jricher@mit.edu> wrote:

> The token lifetime is independent of whether the access token a JWT or
> unstructured. You should get a new access token for every new grant
> request. If you get a refresh token from the auth code response, it's
> expected to be a new value and unrelated to any previous ones because it's
> a new grant. And since you can't use the auth code more than once, the rest
> of your question goes astray - there is nothing to rotate because it's all
> new.
>
> It doesn't matter how you got a refresh token, it's always up to the AS
> whether it wants to rotate the value when you use it.
>
> - Justin
> ------------------------------
> *From:* Indeewari Wijesiri <indeewarii@gmail.com>
> *Sent:* Friday, August 2, 2024 7:36 AM
> *To:* Warren Parad <wparad@rhosys.ch>
> *Cc:* oauth@ietf.org <oauth@ietf.org>
> *Subject:* [OAUTH-WG] Re: Refresh Token Rotation
>
> Hi Warren,
>
> Thank you for your attention.
>
> When public web clients use the authorization code grant for
> authentication, a successful response includes an access token and,
> optionally, a refresh token. If the access token is a JWT rather than an
> opaque token, the identity server will issue a new JWT access token for
> each authentication request with the same client_id and scope, based on the
> "issued at" (iat) claim. This means each authentication attempt generates a
> new JWT access token.
>
> In this context, how should the refresh token behave? Is it advisable to
> use a long-lived refresh token in conjunction with the JWT access token, or
> should the refresh token be rotated each time a new JWT access token is
> issued?
>
> For opaque access tokens, since they are not renewed with each request, a
> long-lived refresh token can be used.
>
> Thanks and regards
>
> On Fri, Aug 2, 2024 at 4:38 PM Warren Parad <wparad@rhosys.ch> wrote:
>
> Indeewari,
>
> I'm confused regarding what you are describing. Would you be able to give
> additional context?
>
> - Warren
>
> On Fri, Aug 2, 2024 at 11:25 AM Indeewari Wijesiri <indeewarii@gmail.com>
> wrote:
>
> Hi all,
>
> Refresh token rotation, which involves issuing a new refresh token each
> time an access token is renewed, is the default for the refresh grant. Do
> we follow the same practice for the authorization code grant and password
> grant as well? What is the recommended practice between long-lived refresh
> tokens and refresh token rotation for these grants?
>
> Additionally, is there a specific requirement for refresh token rotation
> with JWT access tokens in the authorization code grant and password grant,
> given that JWT access tokens are renewed per request?
>
> Thanks and Regards
> --
>
> Indeewari Wijesiri
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
>
>
> --
>
> Indeewari Wijesiri
> Associate Technical Lead, WSO2 Inc
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>