RFC 6749 Section 6 - Refresh Token with scope

[4865783a5d]

Which version of Duende IdentityServer are you using?
7.0.4

Which version of .NET are you using?
NET8

https://datatracker.ietf.org/doc/html/rfc6749#section-6 mentions an optional scope parameter.
Is this feature implemented in the mentioned Duende Identity Server version as we couldn't get it to work?

The TokenRequestValidator.cs code

  var validatedResources = await _resourceValidator.ValidateRequestedResourcesAsync(new ResourceValidationRequest
  {
      Client = _validatedRequest.Client,
      Scopes = _validatedRequest.RefreshToken.AuthorizedScopes,
      ResourceIndicators = resourceIndicators,
  });

is using the AuthorizedScopes from the storage for validation.

We could implement this in the ICustomTokenRequestValidator but were wondering if it is something we're missing there.

[4865783a5d]

@AndersAbel may I ask if you have found anything yet?

Usages of request.Raw.Get with the "scope" parameter seem to be quite limited and not within the /connect/token path for a refresh_token.

https://github.com/search?q=repo%3ADuendeSoftware%2Fproducts+%22var+scope+%3D+request.Raw.Get%22&type=code

Thanks!

[maartenba]

(note: we're moving this issue to our new community discussions)

[RolandGuijt]

We''re looking into this at the moment.
For context can you please let us know why you need this?

[4865783a5d]

@RolandGuijt thanks for your feedback, we don't have a use-case (yet) as a new token with a subset of scopes could be requested instead, we just wanted to cover compatibility with the RFC as we reference those to our developers working with Identity Server.

You are doing a similar check for resource indicators where you compare the requested resource indicator against the original authorize request:

 if (_validatedRequest.RequestedResourceIndicator != null &&
     !_validatedRequest.RefreshToken.AuthorizedResourceIndicators.Contains(_validatedRequest.RequestedResourceIndicator))
 {
     return Invalid(OidcConstants.AuthorizeErrors.InvalidTarget, "Resource indicator does not match any resource indicator in the original authorize request.");
 }

So we thought we're missing something there as there is no matching validation for requested scopes / AuthorizedScopes

[RolandGuijt]

The RFC you provided the link to mentions this is optional. We don't have a use case either at the moment so it doesn't have priority for now.
We will however consider this. I'll add your suggestion to our internal ideas document. Thanks for suggesting it!

Alternatively you could look into resource indicators. These might be a better option because they are organized on the identity provider level and are less client dependent.

[4865783a5d]

We're already using resource indicators for various reasons, thanks.