From neil.e.madden@gmail.com Wed Feb 21 00:28:03 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 EE7B5C151099 for ; Wed, 21 Feb 2024 00:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Pg7ze8Fru_4O for ; Wed, 21 Feb 2024 00:27:59 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 EF46CC15108B for ; Wed, 21 Feb 2024 00:27:58 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-41277695f05so563885e9.0 for ; Wed, 21 Feb 2024 00:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708504077; x=1709108877; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=hJ7+UOLQ/hdgshRbAUIAPqPD144B0r2Ss8S1miRWpMg=; b=Z9XMRIvaxWHHy5ErFOb4BYS79HUqLb/qNfi7X11DF3Nl7yctpMazpBLabaPrDtBTCn h+oLH1VqSla3LnKSov2QDYwkogqCgjz6bnEFdBCLf1CHuF7ocGXSYHdm+Eyq4aDtuqmp Nvi6Fs2Mn2epkHtaD/iGzc9Yf3jLuO1E3hMuohkwDjIMAUxYDNgMe27ZG+vMJlzRR9pE 9wz33Jdy96M3FCxICTtDcUDVgg8eOBFlS0EWMpIf6NcUHuzx8/qPEyVEB4j7Wczgoia/ Oo1EabHpjPIaBvdgtkEaefPUxBAdAXxIQJKCBdYFfRXkkqsEVDvn3VFlvMMUqWuyi2iG Is4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708504077; x=1709108877; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hJ7+UOLQ/hdgshRbAUIAPqPD144B0r2Ss8S1miRWpMg=; b=OpBP5ZrEngRhM2dLOLMQVk9Uez0w1HifBP4Hg3DElfslIij4KNJvrQzkUUeo74oZU+ MZYV9xK+IKbwr11FKDqgF+6dZ4a5ORdGhY7mr4qp4cJMsR6tdSyfXiJcVNOoyZIWXC+A AfJa3SHhE8AxRyBttEsyEUHlCl5pO0r1zRr5Ccl3fMphX8wHxINd4MiZD36FBg7A6C+V 7fkCL+uZPW498VJkhKcdnQ+cPYaMhiYIbYKgYxxPqjuhGIItbqB+BtDSSNtDrWCA2xdE U6BZJv5gOT3DyuN25yKweRw9pxQF5ydwZo0uTHblZmXUx0BFIlYCtwgHillLmya46T69 Dddw== X-Forwarded-Encrypted: i=1; AJvYcCWw480Pf3X9afqQ9QYtVM7r16l5GCsygE7zRe357YguVpa45lyEXXNzFHgUJmgctgC1TISYxDdq9j1Ekng6QQ== X-Gm-Message-State: AOJu0YxLcspembAzq48BP2T7qlgYNKHY1h0yfUoufGr+AuXeuPUTTTwV 69ZuNPVq1PoXc4lTV3t//JXzh8rUt6OJdLl5WfxdcRn9BE9ik1oX X-Google-Smtp-Source: AGHT+IHwFqZb2CdxpOrfSS2orR11vmLi0du5HnijmpoCVQHHyB2prfXDja7eEzO8CzyIN5a5KEPGaQ== X-Received: by 2002:a05:600c:1c11:b0:411:c380:d7b8 with SMTP id j17-20020a05600c1c1100b00411c380d7b8mr12240453wms.0.1708504076980; Wed, 21 Feb 2024 00:27:56 -0800 (PST) Received: from smtpclient.apple ([213.31.127.136]) by smtp.gmail.com with ESMTPSA id q20-20020a7bce94000000b00411d1ce4f9dsm1643077wmj.34.2024.02.21.00.27.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2024 00:27:56 -0800 (PST) From: Neil Madden Message-Id: <11F9493F-CE30-450F-BDC9-3C8DCAC35B28@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A5C5C22-34E1-44AB-85C1-725C58BBC6A7" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Date: Wed, 21 Feb 2024 08:27:55 +0000 In-Reply-To: Cc: wparad@rhosys.ch, oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" To: Sachin Mamoru References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.4) 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:28:04 -0000 --Apple-Mail=_2A5C5C22-34E1-44AB-85C1-725C58BBC6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That section quite clearly says "*access tokens* with identical or = narrower scope". Not refresh tokens. -- Neil > On 21 Feb 2024, at 08:24, Sachin Mamoru = wrote: >=20 > Hi Warren and Neil, >=20 > My basis for asking this is due to the following definition [1], >=20 > 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). >=20 > [1] https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 = >=20 > Thanks & Regards, > Sachin >=20 > On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru > wrote: > Hi Warren and Neil, >=20 > Thanks for the valuable input and sorry for mentioning other products, = I just wanted to provide an example.=20 > So Warren according to you following is the behaviour that spec = suggested. >=20 > When we request an access token using 3 scopes (scope1, scope2, = scope3). >=20 > Then will receive a refresh token (refresh_token1) with the access = token. >=20 > After that will request another access token with refresh_token1 and = provide the scope list as scope1 and scope2 (Narrow down scopes). >=20 > Similarly, get another refresh token (refresh_token2) with the access = token. >=20 > 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. >=20 > 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? >=20 > Thanks & Regards, > Sachin >=20 > 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? Either way, the spec is pretty clear, regardless of what some = vendor does. >=20 > -- Neil >=20 >> On 20 Feb 2024, at 19:26, Sachin Mamoru > wrote: >>=20 >> Hi Neil, >>=20 >> 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. >>=20 >> "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." >>=20 >> [1] = https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access= -token-on-refresh = >>=20 >> Thanks & Regards, >> Sachin >>=20 >> On Tue, 20 Feb 2024 at 21:59, Neil Madden > wrote: >>=20 >>=20 >>> On 20 Feb 2024, at 11:02, Sachin Mamoru > wrote: >>>=20 >>> =EF=BB=BF >>> Hi Neil, >>>=20 >>> Does that mean it should be identical to the narrowed scope request = or the original request scope? >>=20 >> 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. = Whatever scope you specify, any RT returned must always retain the = original scope.=20 >>=20 >> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s = macaroons allow you to attenuate the scope if you wish).=20 >>=20 >> =E2=80=94 Neil >>=20 >>>=20 >>> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru > wrote: >>>=20 >>>=20 >>> On Tue, 20 Feb 2024 at 12:23, Neil Madden > wrote: >>>=20 >>>> On 20 Feb 2024, at 06:44, Sachin Mamoru > wrote: >>>>=20 >>>> =EF=BB=BF >>>> Hi All, >>>>=20 >>>> When we request an access token using 3 scopes (scope1, scope2, = scope3). >>>> Then will receive a refresh token (refresh_token1) with the access = token. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> But in the specification, didn't able to find anything related to = narrow-down scopes with refresh token. >>>>=20 >>>> =46rom Spec >>>>=20 >>>> 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). >>>>=20 >>>> 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. >>>>=20 >>>> https://datatracker.ietf.org/doc/html/rfc6749 = >>>>=20 >>>> 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 the refresh token authorised scopes based on = the requested ones. >>>>=20 >>>> What should be the correct behaviour? >>>> narrow-down scope refresh token should also be able to request = access token with original scope list? >>>=20 >>> Also from section 6: >>>=20 >>> 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. >>>=20 >>>=20 >>>=20 >>>=20 >>> =E2=80=94 Neil >>>=20 >>>=20 >>> --=20 >>>=20 >>> =09 >>> Sachin Mamoru=20 >>> Software Engineer, WSO2 >>> +94771292681 =09 >>> | sachinmamoru.me=C2=A0 >>> sachinmamoru@gmail.com=C2=A0 >>> = >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> =09 >>> Sachin Mamoru=20 >>> Software Engineer, WSO2 >>> +94771292681 =09 >>> | sachinmamoru.me=C2=A0 >>> sachinmamoru@gmail.com=C2=A0 >>> = >>>=20 >>=20 >>=20 >> --=20 >>=20 >> =09 >> Sachin Mamoru=20 >> Software Engineer, WSO2 >> +94771292681 =09 >> | sachinmamoru.me=C2=A0 >> sachinmamoru@gmail.com=C2=A0 >> = >>=20 >=20 >=20 >=20 > --=20 >=20 > =09 > Sachin Mamoru=20 > Software Engineer, WSO2 > +94771292681 =09 > | sachinmamoru.me=C2=A0 > sachinmamoru@gmail.com=C2=A0 > = >=20 >=20 >=20 > --=20 >=20 > =09 > Sachin Mamoru=20 > Software Engineer, WSO2 > +94771292681 =09 > | sachinmamoru.me=C2=A0 > sachinmamoru@gmail.com=C2=A0 > = >=20 --Apple-Mail=_2A5C5C22-34E1-44AB-85C1-725C58BBC6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That section quite clearly says "*access tokens* with = identical or narrower scope". Not refresh tokens.

-- Neil

On 21 Feb 2024, at 08:24, = Sachin Mamoru <sachinmamoru@gmail.com> wrote:

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 <sachinmamoru@gmail.com> 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 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 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? = 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.
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-scop= e-of-access-token-on-refresh

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:

=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. 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 macaroons allow you to attenuate the scope if = you wish). 

=E2=80=94 Neil


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


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

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 = 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.

=46rom 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, 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 the
   request.




=E2=80=94=
 Neil


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

3D""


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

3D""


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

3D""


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

3D""


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

3D""

= --Apple-Mail=_2A5C5C22-34E1-44AB-85C1-725C58BBC6A7--