Hi Sachin, When the authorization server returns a new refresh token as part of refreshing an access token, then the new refresh token MUST have the same scope as the original “old” refresh token (independent from the value of the scope request parameter, e.g. it does not matter whether the client requested narrow scopes for the access token or not). The refresh token represents the “authorization granted to the client by the resource owner” (see section 1.5 of RFC 6749). This grant does not change just because the client refreshes a new access token (which is a flow that does not even include the resource owner). Consequently, section 6 in RFC 6749 states: 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. In other words, the current behaviour is not compliant with the specs because it changes the scope of the refresh token.
The behaviour is correct in the sense that the client cannot request more scopes than the refresh token allows for. The fix is not to allow privilege escalation by enabling a client to request an “access token with original scope list” which is not part of the refresh token (anymore). Instead, maintain the original scope list in the new refresh token. Best regards, Judith Kahrer E: judith.kah...@curity.io W: curity.io > On 20 Feb 2024, at 07:35, 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? > > Your input is highly valuable on this. > > Thanks & Regards, > Sachin > -- > > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
