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 <sachinmam...@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 > <https://datatracker.ietf.org/doc/html/rfc6749#section-1.5> > > Thanks & Regards, > Sachin > > On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru <sachinmam...@gmail.com > <mailto:sachinmam...@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.mad...@gmail.com > <mailto:neil.e.mad...@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 <sachinmam...@gmail.com >> <mailto:sachinmam...@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-scope-of-access-token-on-refresh >> >> <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 <neil.e.mad...@gmail.com >> <mailto:neil.e.mad...@gmail.com>> wrote: >> >> >>> On 20 Feb 2024, at 11:02, Sachin Mamoru <sachinmam...@gmail.com >>> <mailto:sachinmam...@gmail.com>> wrote: >>> >>> >>> 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’s macaroons allow you >> to attenuate the scope if you wish). >> >> — Neil >> >>> >>> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru <sachinmam...@gmail.com >>> <mailto:sachinmam...@gmail.com>> wrote: >>> >>> >>> On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.mad...@gmail.com >>> <mailto:neil.e.mad...@gmail.com>> wrote: >>> >>>> On 20 Feb 2024, at 06:44, Sachin Mamoru <sachinmam...@gmail.com >>>> <mailto:sachinmam...@gmail.com>> wrote: >>>> >>>> >>>> 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 >>>> <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. >>> >>> >>> >>> >>> — Neil >>> >>> >>> -- >>> >>> >>> Sachin Mamoru >>> Software Engineer, WSO2 >>> +94771292681 <tel:+94771292681> >>> | sachinmamoru.me <https://sachinmamoru.me/> >>> sachinmam...@gmail.com <mailto:sachinmam...@gmail.com> >>> <https://www.linkedin.com/in/sachin-mamoru/> >>> <https://twitter.com/MamoruSachin> >>> >>> >>> >>> -- >>> >>> >>> Sachin Mamoru >>> Software Engineer, WSO2 >>> +94771292681 <tel:+94771292681> >>> | sachinmamoru.me <https://sachinmamoru.me/> >>> sachinmam...@gmail.com <mailto:sachinmam...@gmail.com> >>> <https://www.linkedin.com/in/sachin-mamoru/> >>> <https://twitter.com/MamoruSachin> >>> >> >> >> -- >> >> >> Sachin Mamoru >> Software Engineer, WSO2 >> +94771292681 <tel:+94771292681> >> | sachinmamoru.me <https://sachinmamoru.me/> >> sachinmam...@gmail.com <mailto:sachinmam...@gmail.com> >> <https://www.linkedin.com/in/sachin-mamoru/> >> <https://twitter.com/MamoruSachin> >> > > > > -- > > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 <tel:+94771292681> > | sachinmamoru.me <https://sachinmamoru.me/> > sachinmam...@gmail.com <mailto:sachinmam...@gmail.com> > <https://www.linkedin.com/in/sachin-mamoru/> > <https://twitter.com/MamoruSachin> > > > > -- > > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 <tel:+94771292681> > | sachinmamoru.me <https://sachinmamoru.me/> > sachinmam...@gmail.com <mailto:sachinmam...@gmail.com> > <https://www.linkedin.com/in/sachin-mamoru/> > <https://twitter.com/MamoruSachin> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
