From sachinmamoru@gmail.com Wed Feb 21 02:59:52 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 DC859C14F684 for ; Wed, 21 Feb 2024 02:59:52 -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 yCNOfTp04xwi for ; Wed, 21 Feb 2024 02:59:48 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 D47DCC14F5FC for ; Wed, 21 Feb 2024 02:59:47 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-dcdb210cb6aso7198152276.2 for ; Wed, 21 Feb 2024 02:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708513187; x=1709117987; 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=DEijrraeWg0fUKaYK+cTBAtpNkXIDgfGNhT3IDmQNpw=; b=Q6YozLSQFjTCcKeJZkJ+MPwWTFg5SNpZVB8peLeEey+CUUiFIIhxhtuFVq/GIeGcuE 7RYU6gZvD9OM1tfpv+BBWjequ59QxwHgSGjv5pFdz8b7YAU7rAooEWHghhvsgybKEnBn BljMpA/+jXqexeMqxFSZOXGyPuua5xR/MpnhpZByikKvb1So2nRnu1HToybhanxpL1D4 z7GA1NDGVZ+j5iDzCdN5j9Bg+o22eJj42dTcdnDjVXm5E3lhgFMx6AQMnQPX2ZBjpQeU Hh6+rSxXKa2FTWurL2yJVIlf2Xh2SyfZKZtY2luBHZy0Adwyo8Rky+/OX95jqgvnGy4S FM3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708513187; x=1709117987; 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=DEijrraeWg0fUKaYK+cTBAtpNkXIDgfGNhT3IDmQNpw=; b=SEIfqBpM9seXNC/9xagON7HaBxNclpvz6qISZfn3/w05Jh6rEXoT00RG8/NEw8+PpT CE0krKQNLjGPZCeLn8qjgFz2vmo6fPQ4ngPTrIEk/yzecL8fn81JJVs9T0nv/wj9sTHW QFtO2PqLvIdUd4vHxGVLl2QFz+RaoBXEkt8bijVzv6kmb3ctFjZl0VzbOXYoZH+TgscC Fg0p6uGRdmO89WLOIaF7EMJq5M1MZO0d+OeUwHiG9K5nmUaRPaMoD97hevQ4u7wlTg8+ MPX3pnszh59V41ock8HK640aILjbDfyELRCP2iY1ggmuLV7sIABb20F/WduH+9FyAwQB cHaw== X-Forwarded-Encrypted: i=1; AJvYcCXQgIWQsYfYfsnlJSM2ERUxBPk5aZBy+zPDI6Z1Qe4FJKLZ6JXXqw0kigURpHjeYwOVH3+CzFwLkNxmORI3Tg== X-Gm-Message-State: AOJu0Yzlav4bAItHv9fYJKjyQOu9SN20AHXs+EM0sKLWjFDD8vy5DNHR nX2PpsdkXs+g5YLtn5YD1wU3R2A3P6VVuWwp0/wl5IGS+Zy9yOcTcb6oJt2VbFZZ+r2WWiIoEqz gOW7DXLJ051Xz9sH5zcLbSEWs2iM= X-Google-Smtp-Source: AGHT+IF1BkYaR/Ca11IUhuUXX+Ior8k0tjLkeD+vqLwYOwZ+e62bGQAkSMX6Df0+hm6mD5I3F+Ma48PblV0rT2zzBvo= X-Received: by 2002:a25:8a07:0:b0:dc2:466a:23bd with SMTP id g7-20020a258a07000000b00dc2466a23bdmr14801710ybl.54.1708513186761; Wed, 21 Feb 2024 02:59:46 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> <11F9493F-CE30-450F-BDC9-3C8DCAC35B28@gmail.com> In-Reply-To: From: Sachin Mamoru Date: Wed, 21 Feb 2024 16:29:35 +0530 Message-ID: To: Warren Parad Cc: Neil Madden , oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="0000000000009750d60611e2390e" 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 10:59:53 -0000 --0000000000009750d60611e2390e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren, Agree with you on the complexity of our scenario. This is one of the parts of a complex issue we are discussing internally. So according to section 6 of the specification, we can conclude that "the refresh token scope MUST be identical to that of the refresh token included by the client in the request". Thank you, everyone, for the input you have provided regarding the issue. On Wed, 21 Feb 2024 at 15:46, Warren Parad wrote: > Sachin, > > Can I ask what your goal is here, as in what would you like out of this > conversation, what concrete if anything would like this working group to > action? It seems that you have had a question, which has been answered > multiple times (in multiple different email threads, I might add). The > language in the RFC is pretty clear, although, in practice I can see that > the usage might be a bit complex. > > - Warren > > On Wed, Feb 21, 2024 at 10:37=E2=80=AFAM Sachin Mamoru > wrote: > >> Hi Neil, >> >> Since Access tokens are bound to scopes. These scopes define the >> permissions granted for accessing resources. When an access token is >> requested, it's issued with specific scopes based on the authorization >> granted by the resource owner. >> >> On the other hand, Refresh tokens are used to obtain new access tokens >> when the current access token expires or becomes invalid. The critical >> aspect here is that the refresh token itself is not bound by scopes in t= he >> same way access tokens are. Instead, the refresh token carries the >> potential to issue new access tokens with scopes that are the same as or >> narrower than the original scopes granted during the initial authorizati= on >> process. >> >> When you use a refresh token to obtain a new access token, you have the >> option to request a scope that is narrower than the original scope. >> >> This is quite contradicting to me as the spec says that "refresh token >> scopes should be identical to that of the refresh token included by the >> client in the request". - When a refresh token is used to obtain a new >> access token, and a new refresh token is also issued in this process, th= e >> new refresh token must have the same scope as the refresh token that was >> used in the request. >> On the other hand, it says "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". - There's a flexibility= in >> scope when using a refresh token to request new access tokens, but this >> flexibility might seem counterintuitive at first. Specifically, the idea >> that the scope of the new access token can be adjusted (narrowed) withou= t >> altering the permissions granted by the refresh token itself. >> >> Thanks & Regards, >> Sachin >> >> On Wed, 21 Feb 2024 at 13:57, Neil Madden >> wrote: >> >>> 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: >>> >>> 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 th= e >>> authorization server. If the authorization server issues a refresh >>> token, it is included when issuing an access token (i.e., step (D) i= n >>> 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 th= e >>>> 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? = Either >>>>> 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 origi= nal >>>>> scope." >>>>> >>>>> [1] >>>>> https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-a= ccess-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. Wha= tever >>>>>> scope you specify, any RT returned must always retain the original s= cope. >>>>>> >>>>>> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s maca= roons >>>>>> 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 scope= s). >>>>>>>> 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 p= rivilege, >>>>>>>> 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 i= n the >>>>>>>> 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 >>>> >>>> >>>> >>>> >>> >>> -- >>> >>> 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 --0000000000009750d60611e2390e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren,

Agree with you on the comple= xity of our scenario. This is one of the parts of a complex issue we are di= scussing internally. So according to section 6 of the specification, we can= conclude that "the refresh token scope MUST be identical to that of t= he refresh token included by the client in the request".
Tha= nk=C2=A0you, everyone, for the input you have provided regarding the issue.=

On Wed, 21 Feb 2024 at 15:46, Warren Parad <wparad@rhosys.ch> wrote:
Sachin,

C= an I ask what your goal is here, as in what would you like out of this conv= ersation,=C2=A0what concrete=C2=A0if anything would like this working group= to action? It seems that you have had a question, which has been answered = multiple times (in multiple different email threads, I might add). The lang= uage in the RFC is pretty clear, although, in practice I can see that the= =C2=A0usage might be a bit complex.

- Warren
=

= On Wed, Feb 21, 2024 at 10:37=E2=80=AFAM Sachin Mamoru <sachinmamoru@gmail.com> = wrote:
Hi=C2=A0Neil,

Since Access tokens are bound to = scopes. These scopes define the permissions granted for accessing resources= . When an access token is requested, it's issued with specific scopes b= ased on the authorization granted by the resource owner.

On the othe= r hand, Refresh tokens are used to obtain new access tokens when the curren= t access token expires or becomes invalid. The critical aspect here is that= the refresh token itself is not bound by scopes in the same way access tok= ens are. Instead, the refresh token carries the potential to issue new acce= ss tokens with scopes that are the same as or narrower than the original sc= opes granted during the initial authorization process.

When you use = a refresh token to obtain a new access token, you have the option to reques= t a scope that is narrower than the original scope.

This is quite contradicting=C2=A0to me as the spec says that=C2=A0&q= uot;refresh token scopes should be identical=C2=A0to that of the refresh to= ken included by the client in the request". -=C2=A0When a refresh toke= n is used to obtain a new access token, and a new refresh token is also iss= ued in this process, the new refresh token must have the same scope as the = refresh token that was used in the request.
On the other hand, it= says "Refresh tokens are issued to the client by the authorization se= rver and are used to obtain a new access token when the current access toke= n becomes invalid or expires, or to obtain additional access tokens with id= entical or narrower scope". -=C2=A0There's a flexibility in scope = when using a refresh token to request new access tokens, but this flexibili= ty might seem counterintuitive at first. Specifically, the idea that the sc= ope of the new access token can be adjusted (narrowed) without altering the= permissions granted by the refresh token itself.

= Thanks & Regards,
Sachin

On Wed, 21 Feb 2024 at 13:57, N= eil Madden <neil.e.madden@gmail.com> wrote:
That section quite clearly says "*ac= cess 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.= =C2=A0 Refresh
=C2=A0 =C2=A0tokens are issued to the client by the autho= rization server and are
=C2=A0 =C2=A0used to obtain a new access token w= hen the current access token
=C2=A0 =C2=A0becomes invalid or expires, or= to obtain additional access tokens
=C2=A0 =C2=A0with identical or narrower scope (access tokens may have a shorter<= br>=C2=A0 =C2=A0lifetime and fewer permissions than authorized by the resou= rce
=C2=A0 =C2=A0owner).=C2=A0 Issuing a refresh token is optional at th= e discretion of the
=C2=A0 =C2=A0authorization server.=C2=A0 If the auth= orization server issues a refresh
=C2=A0 =C2=A0token, it is included whe= n issuing an access token (i.e., step (D) in
=C2=A0 =C2=A0Figure 1).
=


Thanks & Regards,=
Sachin

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 wan= ted to provide an example.=C2=A0
So Warren according to you follo= wing is the behaviour that spec suggested.

When we request an access token using 3 scopes (scop= e1, scope2, scope3).
Then will receive a refresh token (= refresh_token1) with the access token.

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

Similarly, ge= t another refresh token (refresh_token2) with the access token.

Now if we request another access token with refresh_token2, we shou= ld be able to request scope3 also.
That means the refresh token will not be narrowed down instead on= ly the access token will get narrowed down.

So Warren and Neil, if possible c= an 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 s= copes?

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 th= e scope can be "increased back to the original scope" maybe sugge= sts the effective scope of the refresh token is still the same? Either way,= the spec is pretty clear, regardless of what some vendor does.
<= br>
-- 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=C2=A0the refresh token scopes.
=
"The scope was originally=C2=A0read openid profile=C2=A0and after r= efresh the access was reduced to=C2=A0read profile=C2=A0(i.e., the=C2=A0access_token=C2=A0now only has=C2=A0read profile= =C2=A0scope and any new tokens obtained using the refr= esh token=C2=A0daa38700-ba96-4ef1-8b30-5cb3527aae19=C2=A0will have the same, reduced scope). Note that=C2=A0= increasing=C2=A0the scope of access cannot be done in this way unless first= reduced and increased back to the original scope."
<= br>

Thanks & Regards,
Sa= chin

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


On 20 Feb 2024, at 11:02, Sachin Mamoru <= ;sachinmamoru@g= mail.com> wrote:

=EF=BB=BF
Hi Neil,

Doe= s that mean it should be identical to the narrowed scope request or the ori= ginal request scope?

It s= ays it has to be identical to the scope of the existing refresh token in th= e request, not the scope specified in the request. So effectively you can n= ever 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 mac= aroons allow you to attenuate the scope if you wish).=C2=A0

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


On T= ue, 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> wr= ote:

= =EF=BB=BF
Hi All,

When we request an access token using 3 scopes (scope1, scope2, sc= ope3).
Then will receive = a refresh token (refresh_token1) with the access token.
=
= After that will request another access token with refresh_token1 and provid= e the scope list as scope1 and scope2 (Narrow down scopes).
Similarly, get another refresh token (re= fresh_token2) with the access token.

Now if we request a= nother 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 relate= d 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=
<= td style=3D"padding:0px 4px"> | <= td style=3D"padding:0.01px;font-family:Arial;font-size:12px"> sachinmamoru.m= e=C2=A0
sachinmamoru@gmail.com=C2=A0

3D""

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

3D""

--
=C2=A0= <= /table>
Sachin Mamoru
Software En= gineer, WS= O2
+9477= 1292681
sachinmamoru.me=C2=A0
sachinmamoru@gmail.com=C2=A0
=
<= /tbody>

3D""


--
<= /tbody>
= =C2=A0
Sachin = Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
<= table cellpadding=3D"0" cellspacing=3D"0" style=3D"border-collapse:collapse= ">
sachinmamoru@gmail.com=C2= =A0

=3D""


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

3D""


--
=C2=A0<= /table>
Sachin Mamoru
Software Engineer, WSO2
+94771292681
<= /td>		=
| sachinmamoru.me=C2=A0
sachinmamoru@gma= il.com=C2=A0
=
<= td align=3D"left" style=3D"padding-right:6px;text-align:center;padding-top:= 0px">=

3D""

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

=3D""
--0000000000009750d60611e2390e--