From wparad@rhosys.ch Tue Feb 20 11:41:27 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 4986DC180B5D for ; Tue, 20 Feb 2024 11:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, 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=rhosys.ch 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 nrVXEb_pbxqE for ; Tue, 20 Feb 2024 11:41:22 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 CEA8EC180B59 for ; Tue, 20 Feb 2024 11:41:22 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a27e7b70152so251331366b.0 for ; Tue, 20 Feb 2024 11:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; t=1708458080; x=1709062880; 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=i8XfQ+JE6Xm3/hl0tZ2nPmcqFlac4E2+Q/ddd3/DDYs=; b=B2Ro/fBVaX60vK9OG+xQgvHxNMOcPnG/X34wgVOIzWyLOO6GvvEv0U3MnlycXptfOp nn7xsoVBSmKSiugjYduxGAKxI8fBiFZBmp8+5Nw1dSMnR/YPw850Vx01QDbsmw3ezY0h F/KGVa571VNnv7+SR4PdwcGtRW3DmxvT7XXav1yOttltAiTwxdbQFPWt5fx1FGvc9OVK +4TLBfyvDT1KX8wROAWlbaLlCbzMjIvZ5COlUHQKWVfjFTcmBVdxUs1DBMfJl6hbrdQL CNHBd8mAgJ/stU8lCf0l8yhZMxdOZc3lArdk0sxksVzBwINwt/FiqDi7wunyd8hjKFf4 VlbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708458080; x=1709062880; 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=i8XfQ+JE6Xm3/hl0tZ2nPmcqFlac4E2+Q/ddd3/DDYs=; b=brdZFmtuR2xwywo7siEI3lcK784fkb9u4j0uzaQNFpaEwGn9E5EmL/la8ZIkp1tbBh BryyrYDOu6NBsJ+3gKB/ZtDLjoODrwMcpuNPKWQkchK9AahIXkJQOUoEr2E+mMbpNMMP mf+wUvNc4eHTs94qYQ23lnx547nP2MJSAIqDiwvTU8WApDsB2Goa0Q23f4UrT0Vt19Rf ZJvs/Ad5PmR+ZRnhrBPhzioVV1WiUYZn19aRXsL/wqrLxBGxx60lqaLcyeoNQdGHgPTp jT8UEskdFX/siGoIvKfwNVClE6AJvPjT5bDqu092vGtwFwwlfoAQ4oE50FFkthwij5Dc 564A== X-Forwarded-Encrypted: i=1; AJvYcCV7JwS1iv1tii8LUBKBTa9yUu5wdf6j9Ux400EgEmibjZT37efIFcOzyKVSGTvbP8qEsbHYTRYn7S9xooTDRA== X-Gm-Message-State: AOJu0YyPLTnk9WaDuvwF1/v8xTP0SdmyiYTp9ylsb6D5eNP9MgvAnq3/ aGqcHEWcDPtodylMf3gFwxDiI7cFkfoXWvXibsjC6k7NxmVw9P7d/IylA0drcgHxIU6RApiWY+e IzzqkSOO0ir5XuW8hRTd4T3+Eh9Ox0H1iS/DC X-Google-Smtp-Source: AGHT+IFKzR8Y4Jq5HEFDN7Qh1nLLdRyLgF5PM9xspHjPUYuycL2XgaA5dpg/HH1iceCFZdPE86psXGv6TFgCSMFhJAo= X-Received: by 2002:a17:907:7751:b0:a3e:4919:4fea with SMTP id kx17-20020a170907775100b00a3e49194feamr4886330ejc.0.1708458080403; Tue, 20 Feb 2024 11:41:20 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> In-Reply-To: From: Warren Parad Date: Tue, 20 Feb 2024 20:41:09 +0100 Message-ID: To: Sachin Mamoru Cc: Neil Madden , oauth@ietf.org, janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="000000000000ff31ad0611d5647a" 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:41:27 -0000 --000000000000ff31ad0611d5647a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sachin, Why does it matter what Curity does here? Is the question about what should happen according to the specification or whether or not Curity is compliant with the spec when it comes to refresh tokens? - Warren On Tue, Feb 20, 2024 at 8:27=E2=80=AFPM 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ff31ad0611d5647a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sachin,

Why does it matter what Curity = does here? Is the question about what should happen according to the specif= ication or whether or not Curity is compliant with the spec when it comes t= o refresh tokens?

- Warren

On Tue, Feb 20, 20= 24 at 8:27=E2=80=AFPM Sachin Mamoru <sachinmamoru@gmail.com> wrote:
Hi Neil,

T= hanks 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 refresh the access was reduced to=C2=A0read profile=C2=A0(i.e., the=C2=A0access_token=C2=A0now only has=C2=A0= read profile=C2=A0scope and any n= ew tokens obtained using the 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."


Th= anks & Regards,
Sachin

On Tue, 20 Feb 2024 at 21:59, Nei= l Madden <n= eil.e.madden@gmail.com> wrote:


On 20 Feb 202= 4, at 11:02, Sachin Mamoru <sachinmamoru@gmail.com> wrote:

<= /div>
=EF=BB=BF
H= i Neil,

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

It says it has to be identical to the scope of th= e existing refresh token in the request, not the scope specified in the req= uest. So effectively you can never downscope a refresh token in this way. W= hatever 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 yo= u wish).=C2=A0

=E2=80=94 Neil


On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru <<= a href=3D"mailto:sachinmamoru@gmail.com" target=3D"_blank">sachinmamoru@gma= il.com> wrote:


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

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

=EF=BB=BF
Hi All,

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

Then will re= ceive 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 (Narro= w down scopes).

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


Now if we req= uest another access token with refresh_token2, we cannot request scope3, in= stead, 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.<= /font>


= >From Spec


1.5.=C2=A0 Refresh To= ken -=C2=A0Refresh tokens are issued to the client by the authorization server an= d are=C2=A0used to obtain a new access token when the current access token=C2=A0<= /span>becomes= invalid or expires or to obtain additional access tokens=C2=A0with identical or = narrower scope (access tokens may have a shorter=C2=A0lifetime and fewer permissi= ons than authorized by the resource=C2=A0owner).


6.=C2=A0 Refreshing an Access Token

The scope of the access re= quest as described by=C2=A0Section 3.3.=C2=A0 The requested scope MUST NOT includ= e any scope=C2=A0not originally granted by the resource owner, and if omitted is= =C2=A0= treated as equal to the scope originally granted by the=C2=A0resource 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 request= ed ones.


What should be the correct behaviour?
narrow-do= wn scope refresh token should also be able to request access token with ori= ginal 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"" _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ff31ad0611d5647a--