Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Warren Parad <[e-mail]>]

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 PM Sachin Mamoru <[e-mail]>
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 <[e-mail]> wrote:
>
>>
>>
>> On 20 Feb 2024, at 11:02, Sachin Mamoru <[e-mail]> 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 <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> On Tue, 20 Feb 2024 at 12:23, Neil Madden <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> On 20 Feb 2024, at 06:44, Sachin Mamoru <[e-mail]> 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
>>> [phone]
>>> | sachinmamoru.me  <https://sachinmamoru.me>
>>> [e-mail]  <[e-mail]>
>>> <https://www.linkedin.com/in/sachin-mamoru/>
>>> <https://twitter.com/MamoruSachin>
>>>
>>>
>>
>> --
>>
>> Sachin Mamoru
>> Software Engineer, WSO2
>> [phone]
>> | sachinmamoru.me  <https://sachinmamoru.me>
>> [e-mail]  <[e-mail]>
>> <https://www.linkedin.com/in/sachin-mamoru/>
>> <https://twitter.com/MamoruSachin>
>>
>>
>
> --
>
> Sachin Mamoru
> Software Engineer, WSO2
> [phone]
> | sachinmamoru.me  <https://sachinmamoru.me>
> [e-mail]  <[e-mail]>
> <https://www.linkedin.com/in/sachin-mamoru/>
> <https://twitter.com/MamoruSachin>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>