From sachinmamoru@gmail.com Tue Feb 20 11:26:51 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 7010DC1519AC for ; Tue, 20 Feb 2024 11:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 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, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, 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 EO-sXy3WlZ3G for ; Tue, 20 Feb 2024 11:26:47 -0800 (PST) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 46C44C151078 for ; Tue, 20 Feb 2024 11:26:47 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dcc84ae94c1so5410532276.1 for ; Tue, 20 Feb 2024 11:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708457206; x=1709062006; 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=TDrwc83NdbvFtM0GUor85yUm8CCFWnzFDKOBSudKSMM=; b=KInYxCMs8I0b/wiD2606pj+LCmAjF6+qgOVKWDGYLSb8/Ig+ag5PbPQbzOOhkohb/c C+JZ41tKrmBrAxIcVlkuBGKlawC9FklwFLGijoMrK6S+EL+GLve8nLZ33hseve7bW0ue 5VyMoeGPPQxInKjgDv0WZ5AJSuRo1a854MC6L363mtuq60Wl/4L4H78ordgKpjoseiNu 5PM7K0UBqPk3bOzg2mRxlzq6nLBws6CUVGny5Q/DTiZSsUCG9tWbVkTTV2Qdin8hEnGw YULRhb3L3vupzi/mGQblBuPm0dsIHXsErArQWTlJZCRrmmwb8FLGXba2MZzl3QgCkgpx ntmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708457206; x=1709062006; 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=TDrwc83NdbvFtM0GUor85yUm8CCFWnzFDKOBSudKSMM=; b=lGBb++UOOss3AFqA/W/eBBwpMuyl2NSQk6sbGdcVFJZ0neORmXm+1Y2EtvdTJ2AScL oIhcg4M5KQ+HuDZDJlaFoE0mC8jG/DJt/Cn0jSRvWus5MY783bC4i/k1hc+ZnFUIF7n8 rvvpB1l8hfwTcVttlSC/Frx7EqMlHJhYRWVkWL3AWlo91072YqOokJ+CkO+EjFrp2bYe vDFCZ8PttOVprAG64V45gtjkgNT+N0OpxwOh+ANeh/iZh5qQxC43pWLVJghhVR8GRwMs TQUuJfFsRBWB4GehkI064AJeYDAAC+rk3LFDPpkV6pqwfdUNpJQEg5UyU+7QnFTNd8gS iglA== X-Gm-Message-State: AOJu0Yw/9Jm1+Z3WrPfVFZ/bp65S1Evtmm6jrMLSrlD3xbx/SURSII2Q qYD2itGlO1nv9cW4MCYRl70bvvDYaorlrlwYlYuYW0W8xEop3nU8IZWQnEF4sz6MkQJezTsyKjW Q4XMqcW46kXmaSvtBFs3Nxao1c/CexPfPKaE3WSJe X-Google-Smtp-Source: AGHT+IFIUXcN1mcW+ZiLCTe9a5hmsbk6ECesLjPDfFHxLGgYOUdbPLT1lkzm8+NIboK2ywSJldw27g3i/GGNl+SBIoM= X-Received: by 2002:a25:4f05:0:b0:dc2:232d:7fde with SMTP id d5-20020a254f05000000b00dc2232d7fdemr12049550ybb.13.1708457204817; Tue, 20 Feb 2024 11:26:44 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> In-Reply-To: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> From: Sachin Mamoru Date: Wed, 21 Feb 2024 00:56:33 +0530 Message-ID: To: Neil Madden Cc: oauth@ietf.org, janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="000000000000cea73d0611d53096" 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: Tue, 20 Feb 2024 19:26:51 -0000 --000000000000cea73d0611d53096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-access-= 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 th= e > 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 yo= u > 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 > 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 toke= n. >>> >>> 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 o= r >>> 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, wh= ere >>> it updates the refresh token authorised scopes based on the requested o= nes. >>> >>> >>> 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 >> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me > sachinmamoru@gmail.com > > > > --=20 Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me sachinmamoru@gmail.com --000000000000cea73d0611d53096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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>


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


O= n 20 Feb 2024, at 11:02, Sachin Mamoru <sachinmamoru@gmail.com> wrote:

=EF=BB=BF
Hi Neil,

Does that mean it should be identica= l to the narrowed scope request or the original request scope?
<= /div>

It says it has to be identical to the= scope of the existing refresh token in the request, not the scope specifie= d 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 t= he 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

=E2=80=94 Neil

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


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

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

=EF=BB=BF
Hi All,<= div>

= 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 s= cope2 (Narrow down scopes).

Similarly, get another refresh token (refresh_t= oken2) with the access token.


N= ow if we request another access token with refresh_token2, we cannot reques= t scope3, instead, we can either request both scope1 and scope2 or one of t= hem.


But in the specificati= on, didn't able to find anything related to narrow-down scopes with ref= resh token.


From Spec

1.5.=C2= =A0 Refresh Token -=C2=A0Refresh tokens are issued to the client by the authoriza= tion server and are=C2=A0used to obtain a new access token when the current acces= s token=C2=A0becomes invalid or expires or to obtain additional access tokens=C2= =A0wit= h 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 o= f the access request as described by=C2=A0Section 3.3.=C2=A0 The requested scope = 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=A0= resour= ce owner.


https://datatracker.ietf.org/doc/html/rfc6749=


IMO, from a security aspect, the current behaviou= r is much more secure because it is designed to maintain the principle of l= east 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
<= /div>


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


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

=3D""


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

3D"" --000000000000cea73d0611d53096--