Hi Sachin,
You’re right, the scope of the refresh token MUST remain the same. That means a
refresh token should enable a client to request a new access token with the
“scope originally granted by the resource owner”. Even if a refresh token
entitles a client to request certain scopes
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
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
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
on behalf of Sachin Mamoru
Date: Wednesday, 21. February 2024 at 09:26
To: Neil Madden , "wpa...@rhosys.ch"
Cc: oauth , "ja...@wso2.com" ,
"thilinasenarat...@gmail.com" ,
"pirave...@wso2.com"
Subject: Re: [OAUTH-WG] Evaluation of Scope Management in Refresh
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 wrote:
>
> Hi Warren and Neil,
>
> My basis for asking this is due to the following definition [1],
>
> Refresh tokens are credentials
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
On 21 Feb 2024, at 08:06, Sachin Mamoru 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
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
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.
--
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
wrote:
> Hi Neil,
>
> Thanks
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
On 20 Feb 2024, at 11:02, Sachin Mamoru 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
Hi Neil,
Does that mean it should be identical to the narrowed scope request or the
original request scope?
On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru wrote:
>
>
> On Tue, 20 Feb 2024 at 12:23, Neil Madden wrote:
>
>>
>> On 20 Feb 2024, at 06:44, Sachin Mamoru wrote:
>>
>>
>> Hi All,
>>
On Tue, 20 Feb 2024 at 12:23, Neil Madden wrote:
>
> On 20 Feb 2024, at 06:44, Sachin Mamoru 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
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
> On 20 Feb 2024, at 06:44, Sachin Mamoru 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
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).
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).
19 matches
Mail list logo
