From sachinmamoru@gmail.com Wed Feb 21 00:24:47 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 6041CC15109E for ; Wed, 21 Feb 2024 00:24:47 -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_DNSWL_NONE=-0.0001, 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 Gtxru6LDn_5q for ; Wed, 21 Feb 2024 00:24:42 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 A7F2DC15152C for ; Wed, 21 Feb 2024 00:24:42 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dcc71031680so5122735276.2 for ; Wed, 21 Feb 2024 00:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708503882; x=1709108682; 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=gPSzhLpdsNTQTofQ8LGqrzORHIYHBWyWE+IxRClccPQ=; b=UwKH8V4I00r5XMjG+Gyy+7EV6He2AVAUUTt7rqeV44MGj6GlW29qrTY+OsQqd5/T9a NXqu+wnDm6D/cp9kuT1ewahKci/n8fZ+iS79d/U1CGiOv6tpBdTO7Y3xQXydNFRYJocD Zcl+0yodLZ7k4nCafy6Cd7/qPftRtgmnuYvBNSXLtUZTmI7ROWF9jSbNxR30xLRhzGUd higBDUy9G+gyfVTLFnE9cBouB+wDoPbh40AWMTs/yP2/YoJJJCRNzy3GOHeWxSkMZii/ oH9kWuPF8QW0UnifWkzyI9ywAod85hXYq/fW7IuNMXsvb75jfGFGWV7mXa2P25OwtR12 jghg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708503882; x=1709108682; 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=gPSzhLpdsNTQTofQ8LGqrzORHIYHBWyWE+IxRClccPQ=; b=WzEiQDeQttogPeH4yb6n7ugPri1w8fiY3rlJ75qkuo76u5DSruBHt2fd2iVUbCL9GF eifAbhq8wrgSj9arIobnGf2OHdkcXgQokenpk95XBPZ57AX1WMyPwqsM7xdBjTozKcA6 mn/1rY4F4nBLRraKA22g4dwBV6Xxj7e48fe5/tZsT0dSBe2HfSRAtN5TWwLfL18nFdou pyEzTWMZ9ohCf8bRM5njLVRoL2L0Y0s+82PEQd3bHf06emIYFuxMlt0yxCuipEmwYh6H cJiZrCO7p1JR14DWJkO+DLb2Oq5qHU1cmYJvhKVd6rrV6JKHKsbqFN0FcSOWX80Vixld wO+Q== X-Gm-Message-State: AOJu0YxX5ifJ8/vmDWmPzu6dsg3PQeq6Wvh3rosfbL0LpGoH4HrO4JXD PKBJi0PpRIxbXkOSbdoGRzP7DyhyOBax2iMTVqdFe+nOnTXW9heywXtTpH5ogS6fuyoF2q24UPh yTKN4gjmn4fXD7fYaLEQmTj1xaTjyoTdfwi04D3Gu X-Google-Smtp-Source: AGHT+IHG1LFiSaznomRMM/+3jAJo/iZr6K234V3Luz+/pnZuMYVntSUSuNow73bCopkVHbq+9mw35DYq1iE9huu50nI= X-Received: by 2002:a25:b20f:0:b0:dc6:9b89:3f75 with SMTP id i15-20020a25b20f000000b00dc69b893f75mr16009434ybj.40.1708503880309; Wed, 21 Feb 2024 00:24:40 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> In-Reply-To: From: Sachin Mamoru Date: Wed, 21 Feb 2024 13:54:28 +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="000000000000e221bb0611e00e8d" 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:24:47 -0000 --000000000000e221bb0611e00e8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren and Neil, My basis for asking this is due to the following definition [1], Refresh tokens are credentials used to obtain access tokens. 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). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1). [1] https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 Thanks & Regards, Sachin On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru wrote: > 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 b= e > 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? Eit= her >> 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 = read >> 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-acce= ss-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 >>> token in the request, not the scope specified in the request. So >>> effectively you can never downscope a refresh token in this way. Whatev= er >>> scope you specify, any RT returned must always retain the original scop= e. >>> >>> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s macaroo= ns 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 secur= e >>>>> because it is designed to maintain the principle of least privilege, = where >>>>> 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 t= he >>>>> 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 >> >> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me > sachinmamoru@gmail.com > > > > --=20 Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me sachinmamoru@gmail.com --000000000000e221bb0611e00e8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren and Neil,

My b= asis for asking this is due to the following definition [1],

=
Refresh tokens are credentials used to obtain access tokens.=C2=A0 Re= fresh
=C2=A0 =C2=A0tokens are issued to the client by the authorization = server and are
=C2=A0 =C2=A0used to obtain a new access token when the c= urrent access token
=C2=A0 =C2=A0becomes invalid or expires, or to obtai= n additional access tokens
=C2=A0 =C2=A0with identical or narrower scope (access tokens may have a shorter
=C2=A0= =C2=A0lifetime and fewer permissions than authorized by the resource
= =C2=A0 =C2=A0owner).=C2=A0 Issuing a refresh token is optional at the discr= etion of the
=C2=A0 =C2=A0authorization server.=C2=A0 If the authorizati= on server issues a refresh
=C2=A0 =C2=A0token, it is included when issui= ng an access token (i.e., step (D) in
=C2=A0 =C2=A0Figure 1).


On= Wed, 21 Feb 2024 at 13:36, Sachin Mamoru <sachinmamoru@gmail.com> wrote:
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 following is the behaviour that spec suggested.<= /div>

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


Then will rec= eive a refresh token (refresh_token1) with the access token.<= /p>

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


= Similarly, get a= nother refresh token (refresh_token2) with the access token.<= /p>

Now if we request another access token with r= efresh_token2, we should be able to request scope3 also.

<= p dir=3D"ltr" style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">That means the ref= resh 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 exac= t place in the spec where it does explicitly say that the refresh token sho= uld 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 sounds like they are violating the s= pec 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? Either way, the spec is pretty clear, reg= ardless of what some vendor does.

-- Neil
=
On 20 Feb 2024, at 19:26, Sachin Mamoru = <sachinmamor= u@gmail.com> wrote:

Hi Neil,

=
Thanks for the clarification.
But Curity has a differe= nt approach and they implemented it according to the concept of narrowing d= own=C2=A0the refresh token scopes.

"The scope was originally=C2=A0read openid profile= =C2=A0and after refresh the access was reduced = to=C2=A0read profile=C2=A0(i.e., = the=C2=A0access_token=C2=A0now on= ly has=C2=A0read profile=C2=A0sco= pe and any new tokens obtained using the refresh token=C2=A0d= aa38700-ba96-4ef1-8b30-5cb3527aae19=C2=A0will h= ave the same, reduced scope). Note that=C2=A0increasing=C2=A0the scope of ac= cess cannot be done in this way unless first reduced and increased back to = the original scope."


=
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 <sachinmamoru@gmail.com> wrote:

<= /blockquote>
=EF=BB=BF
Hi Neil,

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

It says it has to be identical to th= e scope of the existing refresh token in the request, not the scope specifi= ed in the request. So effectively you can never downscope a refresh token i= n 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 th= e scope if you wish).=C2=A0

=E2=80=94 Neil

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


On Tue, 20 Feb 2024 at 12:23, Neil = Madden <nei= l.e.madden@gmail.com> wrote:

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

=EF=BB=BF
Hi Al= l,

When we request an acc= ess 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 t= oken.

Now if we request another access token with refres= h_token2, we cannot request scope3, instead, we can either request both sco= pe1 and scope2 or one of them.

But in the specificat= ion, didn't able to find anything related to narrow-down scopes with re= fresh token.

From Spec

1.5.=C2=A0 Refresh Token -=C2=A0Refresh tokens are issued to the client by the au= thorization server and are=C2=A0used to obtain a new access token when the current access token=C2= =A0becomes invalid or e= xpires or to obtain additional access tokens=C2=A0with identical or narrower scope (access tokens = may have a shorter=C2=A0lifetime and fewer permissions than authorized by the resource=C2=A0owner).

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


IMO, from a security aspect, the current behav= iour is much more secure because it is designed to maintain the principle o= f least privilege, where it updates the refresh token authorised scopes bas= ed on the requested ones.

What should be the correct behaviour?
narrow-d= own scope refresh token should also be able to request access token with or= iginal scope list?
<= /div>

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""


--
<= /table>
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681
| sachinmamoru.me=C2=A0<= /td>
sachin= mamoru@gmail.com=C2=A0
=

=3D""
--000000000000e221bb0611e00e8d--