From sachinmamoru@gmail.com Wed Feb 21 00:07:04 2024 Return-Path: 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 62861C14F709 for ; Wed, 21 Feb 2024 00:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, 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=gmail.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 UWiIdZBnvQUl for ; Wed, 21 Feb 2024 00:06:59 -0800 (PST) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D9EC14F6FA for ; Wed, 21 Feb 2024 00:06:59 -0800 (PST) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-607c5679842so3038997b3.2 for ; Wed, 21 Feb 2024 00:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708502819; x=1709107619; 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=3cn3PWJYtH/k+z5OIa4ozMRTwoWxVwfs2rKTMBi6IBI=; b=J7cOhDA3JGuuPYKzXDnFGC8tWShzmuWtWwK6XQ/zWTy/fXD0/R11cL2XI9OTMXKaPE ib2psQGcl7vjf8EPldV9BpYq8XdKg4RE9rR14TNjNAqSpt6YQvvcFTxD5Zu4DPYWaP3N p9LZFP5q+/xb4G1ngrx9UhQDO5u/I0dRW/i/Y/3wzySTOzS7RcHMVAWD/aP2h+a5fOhh ccoVu9lN4w/5azBRsX23BRjLkgfGpgvj0YZ22StK+CF43mbgWKZRTAs/TE1ZgKPTyfgm O9ngFAg5zazOBkMg9GClMeDKzlji2ukikuoQ67pHkOxA9Fx0lrBK4Mi8Xt5RXvYGB1CM aOZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708502819; x=1709107619; 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=3cn3PWJYtH/k+z5OIa4ozMRTwoWxVwfs2rKTMBi6IBI=; b=H+W92MLFp0JGAVCkes6Yz0nUHVeM1GiQPtYWIj8DGDWZwD0cJ9brGNYeO7bpJFHWaU 75GvNnh1b/KaU3bbmaBZFig8VrCwQyzAhTtrTeaT1k/sTDzc6YWkSR5HPX0HnQRpTyIt cN+sNvgOzwNjax/mNYOH5A/vPB9kEA5N6u+lWBGOj/EXuHRC5eFoXsOULIvc6GabnY8D DYS5zMWf6gKQ76sCDqAjVuJR4lTuFB39zOqpfd57sItXbaC0l/a0w+UWJdNnZr18P4vq 5jUzjIM95NWtH29aHU8lV0WwyHrO9vB4fiKjMJxljd7ZRBHn6xfseXRR+0LeRN1MrGLy nDpw== X-Gm-Message-State: AOJu0Yy04PVv6PGlCFEdej8YpM3htU6WUd2xlCIaXP1RbvNmfVBSgmc1 1Qn3WyKLPu8WOghzlOnwYe1j6L4ffdViyQNLoAiN1TtTNspxDyIYD8hz/6oNnEXik0P0Wsj5+vK yU5pY15CKa5FNzn72wXuNX2koPpsLg7gussBLjOHq X-Google-Smtp-Source: AGHT+IFHsiTzCx0E0EXJY73DR+y7I8kwQatrCGSxp/TLvhsGMDkIIInORB/U3/GXxdd5eLCRsfH9DRl0kwxFdk/9Jks= X-Received: by 2002:a05:6902:4f1:b0:dbf:6267:eba4 with SMTP id w17-20020a05690204f100b00dbf6267eba4mr15360586ybs.27.1708502818614; Wed, 21 Feb 2024 00:06:58 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> In-Reply-To: <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> From: Sachin Mamoru Date: Wed, 21 Feb 2024 13:36:47 +0530 Message-ID: To: Neil Madden , wparad@rhosys.ch Cc: oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="00000000000099f2280611dfcff9" Archived-At: Subject: Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2024 08:07:04 -0000 --00000000000099f2280611dfcff9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren and Neil, Thanks for the valuable input and sorry for mentioning other products, I just wanted to provide an example. So Warren according to you following is the behaviour that spec suggested. When we request an access token using 3 scopes (scope1, scope2, scope3). Then will receive a refresh token (refresh_token1) with the access token. After that will request another access token with refresh_token1 and provide the scope list as scope1 and scope2 (Narrow down scopes). Similarly, get another refresh token (refresh_token2) with the access token= . Now if we request another access token with refresh_token2, we should be able to request scope3 also. That means the refresh token will not be narrowed down instead only the access token will get narrowed down. So Warren and Neil, if possible can you pinpoint to me the exact place in the spec where it does explicitly say that the refresh token should not be narrowed down based on the given scopes? Thanks & Regards, Sachin On Wed, 21 Feb 2024 at 01:12, Neil Madden wrote: > It sounds like they are violating the spec then. On the other hand, the > fact that the scope can be "increased back to the original scope" maybe > suggests the effective scope of the refresh token is still the same? Eith= er > way, the spec is pretty clear, regardless of what some vendor does. > > -- Neil > > On 20 Feb 2024, at 19:26, Sachin Mamoru wrote: > > Hi Neil, > > Thanks for the clarification. > But Curity has a different approach and they implemented it according to > the concept of narrowing down the refresh token scopes. > > "The scope was originally read openid profile and after refresh the > access was reduced to read profile (i.e., the access_token now only has r= ead > profile scope and any new tokens obtained using the refresh token > daa38700-ba96-4ef1-8b30-5cb3527aae19 will have the same, reduced scope). > Note that *increasing* the scope of access cannot be done in this way > unless first reduced and increased back to the original scope." > > [1] > https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-acces= s-token-on-refresh > > Thanks & Regards, > Sachin > > On Tue, 20 Feb 2024 at 21:59, Neil Madden wrote= : > >> >> >> On 20 Feb 2024, at 11:02, Sachin Mamoru wrote: >> >> =EF=BB=BF >> Hi Neil, >> >> Does that mean it should be identical to the narrowed scope request or >> the original request scope? >> >> >> It says it has to be identical to the scope of the existing refresh toke= n >> in the request, not the scope specified in the request. So effectively y= ou >> can never downscope a refresh token in this way. Whatever scope you >> specify, any RT returned must always retain the original scope. >> >> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s macaroon= s allow >> you to attenuate the scope if you wish). >> >> =E2=80=94 Neil >> >> >> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru >> wrote: >> >>> >>> >>> On Tue, 20 Feb 2024 at 12:23, Neil Madden >>> wrote: >>> >>>> >>>> On 20 Feb 2024, at 06:44, Sachin Mamoru wrote= : >>>> >>>> =EF=BB=BF >>>> Hi All, >>>> >>>> When we request an access token using 3 scopes (scope1, scope2, scope3= ). >>>> Then will receive a refresh token (refresh_token1) with the access >>>> token. >>>> >>>> After that will request another access token with refresh_token1 and >>>> provide the scope list as scope1 and scope2 (Narrow down scopes). >>>> Similarly, get another refresh token (refresh_token2) with the access >>>> token. >>>> >>>> Now if we request another access token with refresh_token2, we cannot >>>> request scope3, instead, we can either request both scope1 and scope2 = or >>>> one of them. >>>> >>>> But in the specification, didn't able to find anything related to >>>> narrow-down scopes with refresh token. >>>> >>>> From Spec >>>> >>>> 1.5. Refresh Token - Refresh tokens are issued to the client by the >>>> authorization server and are used to obtain a new access token when >>>> the current access token becomes invalid or expires or to obtain >>>> additional access tokens with identical or narrower scope (access >>>> tokens may have a shorter lifetime and fewer permissions than >>>> authorized by the resource owner). >>>> >>>> 6. Refreshing an Access Token >>>> The scope of the access request as described by Section 3.3. The >>>> requested scope MUST NOT include any scope not originally granted by >>>> the resource owner, and if omitted is treated as equal to the scope >>>> originally granted by the resource owner. >>>> >>>> https://datatracker.ietf.org/doc/html/rfc6749 >>>> >>>> IMO, from a security aspect, the current behaviour is much more secure >>>> because it is designed to maintain the principle of least privilege, w= here >>>> it updates the refresh token authorised scopes based on the requested = ones. >>>> >>>> What should be the correct behaviour? >>>> narrow-down scope refresh token should also be able to request access >>>> token with original scope list? >>>> >>>> >>>> Also from section 6: >>>> >>>> If a >>>> new refresh token is issued, the refresh token scope MUST be >>>> identical to that of the refresh token included by the client in th= e >>>> request. >>>> >>>> >>>> >>>> >>>> >>>> =E2=80=94 Neil >>>> >>>> >>> >>> -- >>> >>> Sachin Mamoru >>> Software Engineer, WSO2 >>> +94771292681 >>> | sachinmamoru.me >>> sachinmamoru@gmail.com >>> >>> >>> >>> >> >> -- >> >> Sachin Mamoru >> Software Engineer, WSO2 >> +94771292681 >> | sachinmamoru.me >> sachinmamoru@gmail.com >> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me > sachinmamoru@gmail.com > > > > > --=20 Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me sachinmamoru@gmail.com --00000000000099f2280611dfcff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Warren and Neil,

Thanks for the= valuable input and sorry for mentioning=C2=A0other products, I just wanted= to provide an example.=C2=A0
So Warren according to you followin= g is the behaviour that spec suggested.

When we request an access token using 3 = scopes (scope1, scope2, scope3).



After that will request anothe= r access token with refresh_token1 and provide the scope list as scope1 and= scope2 (Narrow down scopes).


S= imilarly, get another refresh token (refresh_token2) with the access token.=


Now if we request another acce= ss token with refresh_token2, we should be able to request scope3 also.

Tha= t means the refresh token will not be narrowed down instead only the access= token will get narrowed down.

<= /div>
So Warren and Neil, if possible can you pinpoint= to me the exact place in the spec where it does explicitly say that the re= fresh token should not be narrowed down based on the given scopes?

Thanks & Regards,
Sachin

On Wed, 21 Feb= 2024 at 01:12, Neil Madden <= neil.e.madden@gmail.com> wrote:
It so= unds like they are violating the spec then. On the other hand, the fact tha= t the scope can be "increased back to the original scope" maybe s= uggests the effective scope of the refresh token is still the same? Either = way, the spec is pretty clear, regardless of what some vendor does.

-- Neil

On 20 = Feb 2024, at 19:26, Sachin Mamoru <sachinmamoru@gmail.com> wrote:

=
Hi Neil,

Thanks for the clarification.<= /div>
But Curity has a different approach and they implemented it accor= ding to the concept of narrowing down=C2=A0the refresh token scopes.
<= div>
"The scope was originally=C2= =A0read openid profile=C2=A0and a= fter refresh the access was reduced to=C2=A0read profile=C2=A0(i.e., the=C2=A0access_token=C2=A0now only has=C2=A0read profile<= /code>=C2=A0scope and any new tokens obtained using th= e refresh token=C2=A0daa38700-ba96-4ef1-8b30-5cb3527aae19=C2=A0will have the same, reduced scope). Note that= =C2=A0increasing=C2=A0the scope of access cannot be done in this way unless = first reduced and increased back to the original scope."
<= div>

Thanks & Regards,
Sachin

On Tue, 20 Feb 2024 at 21:59, Neil Madden <neil.e.madden@gmail.com= > wrote:


On 20 Feb 2024, at 11:02, Sachin Mamoru= <sachinmamo= ru@gmail.com> wrote:

=EF=BB=BF
Hi Neil,

Does that mean it should be identical to the narrowed scope request or the= original request scope?

= It says it has to be identical to the scope of the existing refresh token i= n the request, not the scope specified in the request. So effectively you c= an never downscope a refresh token in this way. Whatever scope you specify,= any RT returned must always retain the original scope.=C2=A0
(There are other ways to downscope a RT, eg ForgeRock=E2=80=99s= macaroons allow you to attenuate the scope if you wish).=C2=A0
<= br>
=E2=80=94 Neil


= On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru <sachinmamoru@gmail.com> wrote:
<= /div>

On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.madden@gmail.com> wrote:
=
<= div dir=3D"ltr">

On 20 Feb 2024, at 06:44, Sachin Mamoru <sachinmamoru@gmail.com>= ; wrote:

=EF=BB=BF
Hi All,

When we request an access token using 3 scopes (scope1, scope2,= scope3).
Then will recei= ve a refresh token (refresh_token1) with the access token.
After that will request another access token with refresh_token1 and pro= vide the scope list as scope1 and scope2 (Narrow down scopes).
Similarly, get another refresh token = (refresh_token2) with the access token.

Now if we reques= t another access token with refresh_token2, we cannot request scope3, inste= ad, we can either request both scope1 and scope2 or one of them.
=

But in the specification, didn't able to find anything rel= ated to narrow-down scopes with refresh token.

From Spec

1.5.=C2=A0 Refresh Toke= n -=C2=A0Refresh tokens= are issued to the client by the authorization server and are=C2=A0<= span style=3D"background-color:transparent">used to obtain a new access tok= en when the current access token=C2=A0becomes invalid or expires or to obtain additional access to= kens=C2=A0with identica= l or narrower scope (access tokens may have a shorter=C2=A0lifetime and fewer permissions than aut= horized by the resource=C2=A0owner).

= 6.=C2=A0 Refreshing an Access Token=
The scope of the access request= as described by=C2=A0S= ection 3.3.=C2=A0 The requested scope MUST NOT include any scope=C2=A0not originally granted by th= e resource owner, and if omitted is=C2=A0treated as equal to the scope originally granted by the= =C2=A0resource owner.

https://datatracker.ietf.org/doc/html/rfc6749<= /div>

IMO, from= a security aspect, the current behaviour is much more secure because it is= designed to maintain the principle of least privilege, where it updates th= e refresh token authorised scopes based on the requested ones.
=

<= div style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">What should = be the correct behaviour?
narrow-down scope refresh token should also be= able to request access token with original scope list?

Also from section 6:

If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.
=




=E2=80=94 Neil
<= /div>


--
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681
=
| sachinmamoru.me=C2=A0
sachinmamoru@gma= il.com=C2=A0
=
=

3D""


--
=C2=A0
Sachin= Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
=
sachinmamoru@gmail.com=C2= =A0

3D""


--
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681
=
| sachinmamoru.me=C2=A0<= /span>
<= /tr>
<= a href=3D"mailto:sachinmamoru@gmail.com" style=3D"text-decoration:unset;fon= t-size:12px;font-family:Arial" target=3D"_blank"> sachinmamoru@gmail.com=C2=A0
<= /table>
3D""



--
=C2=A0
<= span style=3D"font-family:Arial;text-transform:initial;font-weight:bold"> Sachin Mamoru <= /span>
Software= Engineer, = WSO2
= +94771292681
| sachinmamoru.me=C2=A0
<= td style=3D"line-height:0;padding:0.01px 0.01px 6px">
sachinmamoru@gmail.com=C2=A0
=

3D""
--00000000000099f2280611dfcff9--