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

[Sachin Mamoru <[e-mail]>]

Hi Warren,

Agree with you on the complexity of our scenario. This is one of the parts
of a complex issue we are discussing internally. So according to section 6
of the specification, we can conclude that "the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request".
Thank you, everyone, for the input you have provided regarding the issue.

On Wed, 21 Feb 2024 at 15:46, Warren Parad <[e-mail]> wrote:

> Sachin,
>
> Can I ask what your goal is here, as in what would you like out of this
> conversation, what concrete if anything would like this working group to
> action? It seems that you have had a question, which has been answered
> multiple times (in multiple different email threads, I might add). The
> language in the RFC is pretty clear, although, in practice I can see that
> the usage might be a bit complex.
>
> - Warren
>
> On Wed, Feb 21, 2024 at 10:37 AM Sachin Mamoru <[e-mail]>
> wrote:
>
>> Hi Neil,
>>
>> Since Access tokens are bound to scopes. These scopes define the
>> permissions granted for accessing resources. When an access token is
>> requested, it's issued with specific scopes based on the authorization
>> granted by the resource owner.
>>
>> On the other hand, Refresh tokens are used to obtain new access tokens
>> when the current access token expires or becomes invalid. The critical
>> aspect here is that the refresh token itself is not bound by scopes in the
>> same way access tokens are. Instead, the refresh token carries the
>> potential to issue new access tokens with scopes that are the same as or
>> narrower than the original scopes granted during the initial authorization
>> process.
>>
>> When you use a refresh token to obtain a new access token, you have the
>> option to request a scope that is narrower than the original scope.
>>
>> This is quite contradicting to me as the spec says that "refresh token
>> scopes should be identical to that of the refresh token included by the
>> client in the request". - When a refresh token is used to obtain a new
>> access token, and a new refresh token is also issued in this process, the
>> new refresh token must have the same scope as the refresh token that was
>> used in the request.
>> On the other hand, it says "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". - There's a flexibility in
>> scope when using a refresh token to request new access tokens, but this
>> flexibility might seem counterintuitive at first. Specifically, the idea
>> that the scope of the new access token can be adjusted (narrowed) without
>> altering the permissions granted by the refresh token itself.
>>
>> Thanks & Regards,
>> Sachin
>>
>> On Wed, 21 Feb 2024 at 13:57, Neil Madden <[e-mail]>
>> wrote:
>>
>>> 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 <[e-mail]> 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
>>>
>>> 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>
>>>
>>>
>>>
>>
>> --
>>
>> 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>