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 <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> 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> 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 >> >> Thanks & Regards, >> Sachin >> >> On Tue, 20 Feb 2024 at 21:59, Neil Madden <neil.e.mad...@gmail.com> >> wrote: >> >>> >>> >>> On 20 Feb 2024, at 11:02, Sachin Mamoru <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> >>> wrote: >>> >>>> >>>> >>>> On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.mad...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> On 20 Feb 2024, at 06:44, Sachin Mamoru <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 >>>>> >>>>> 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 >>>> | sachinmamoru.me <https://sachinmamoru.me/> >>>> sachinmam...@gmail.com <sachinmam...@gmail.com> >>>> <https://www.linkedin.com/in/sachin-mamoru/> >>>> <https://twitter.com/MamoruSachin> >>>> >>>> >>> >>> -- >>> >>> Sachin Mamoru >>> Software Engineer, WSO2 >>> +94771292681 >>> | sachinmamoru.me <https://sachinmamoru.me/> >>> sachinmam...@gmail.com <sachinmam...@gmail.com> >>> <https://www.linkedin.com/in/sachin-mamoru/> >>> <https://twitter.com/MamoruSachin> >>> >>> >> >> -- >> >> Sachin Mamoru >> Software Engineer, WSO2 >> +94771292681 >> | sachinmamoru.me <https://sachinmamoru.me/> >> sachinmam...@gmail.com <sachinmam...@gmail.com> >> <https://www.linkedin.com/in/sachin-mamoru/> >> <https://twitter.com/MamoruSachin> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me <https://sachinmamoru.me> > sachinmam...@gmail.com <sachinmam...@gmail.com> > <https://www.linkedin.com/in/sachin-mamoru/> > <https://twitter.com/MamoruSachin> > > -- Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me <https://sachinmamoru.me> sachinmam...@gmail.com <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
