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

[Sachin Mamoru <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[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>
>>
>>
>>
>
> --
>
> 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>