On 21 Feb 2024, at 08:06, Sachin Mamoru <sachinmam...@gmail.com> 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?
I have already pointed out the exact place in the spec that says this:
https://www.rfc-editor.org/rfc/rfc6749#section-6
<https://www.rfc-editor.org/rfc/rfc6749#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.
In your example, refresh_token1 has scope1, scope2, scope3 so therefore
refresh_token2 must also have those scopes.
-- Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
