Add Scopes to ClientCredentials Grant Type

There is a current GitLab issue addressing this problem: https://github.com/thephpleague/oauth2-client/issues/774#issuecomment-64...

Scopes can be defined using object notation.

 *   scopes = {
 *    "https://api.payments.auspost.com.au/payhive/payments/read",
 *    "https://api.payments.auspost.com.au/payhive/payments/write",
 *   },

Use this with the change I suggested in the GitLab issue linked to in #5.

Also see: #3046879: Change optionprovider to get the token

+++ b/README.md
@@ -62,7 +62,7 @@ namespace Drupal\oauth2_client\Plugin\Oauth2Client;
+ *   scopes = "basic, firebase, openid",

This is not correct. It should be a json object, see #3150757: Fix scopes documentation in README.md. The module just needs to be fixed to use it properly. See the other issues.

I think this is a duplicate of other issues, unless you can point out what this does which is different.

Since Oauth2ClientPluginBase is designed to handle scopes, it should work with the declared scopes, rather than having to #3046879: Change optionprovider to get the token or use #3256272: Additional parameters to get Access token.

Something along the lines of the second half of jumoke's patch:

$client = $this->getClient($clientId);
$options = ['scope' => $client->getScopes()];

$accessToken = $provider->getAccessToken('client_credentials', $options);

This MR provides a workaround:

 // Declared in custom plugin
  public function getRequestOptions() {
    return [
      'scope' => 'student_logistics_requests:create'
    ];
  }

 // ClientCredentialsGrantService.php
    $client = $this->getClient($pluginId);
    $provider = $this->getProvider($pluginId);
    $options = array_merge(['code' => $code], $client->getRequestOptions());

...but it sure would be cleaner to just use the 'scopes' declared in the plugin annotation.

I'm not clear on how we are not already using scopes with the code as it is:

They are a named parameter in the upstream GenericProvider.

We populate that parameter from our plugin definition

/**
   * Creates a new provider object.
   *
   * @param string $pluginId
   *   The client for which a provider should be created.
   *
   * @return \League\OAuth2\Client\Provider\GenericProvider
   *   The provider of the OAuth2 Server.
   *
   * @throws \Drupal\oauth2_client\Exception\InvalidOauth2ClientException
   *   Exception thrown when trying to retrieve a non-existent OAuth2 Client.
   */
  protected function getProvider($pluginId) {
    if (isset($this->clientProviderCache[$pluginId])) {
      $provider = $this->clientProviderCache[$pluginId];
    }
    else {
      $client = $this->getClient($pluginId);

      $provider = new GenericProvider([
        'clientId' => $client->getClientId(),
        'clientSecret' => $client->getClientSecret(),
        'redirectUri' => $client->getRedirectUri(),
        'urlAuthorize' => $client->getAuthorizationUri(),
        'urlAccessToken' => $client->getTokenUri(),
        'urlResourceOwnerDetails' => $client->getResourceUri(),
        'scopes' => $client->getScopes(),
        'scopeSeparator' => $client->getScopeSeparator(),
      ]);
      $this->clientProviderCache[$pluginId] = $provider;
    }
    return $provider;
  }

Most of which is code inherited from previous maintainers, but if I add scopes = {"foo", "bar"} to a plugin annotation and inspect the instantiated provider at the return above, the scopes property in the GenericProvder is properly initialized with the expected array.

I found an upstream issue: [Question] Client Credentials Grant with scope which lead to a deeper exploration of the Oauth2 Client library code.

Our scopes property in the plugin definition gets passed to the GenericProvider as shown in #11 and becomes \League\OAuth2\Client\Provider\GenericProvider::$scopes . Within the library, that property is accessed via GenericProvider::getDefaultScopes which is only called in the library by \League\OAuth2\Client\Provider\AbstractProvider::getAuthorizationParameters which is only used to build the url for \Drupal\oauth2_client\Service\Grant\AuthorizationCodeGrantService::getAccessToken

Following the guidance of that issue, I propose to create a ClientCredentialsOptionProvider and inject it before the access token is requested our Client Credentials service

Successfully tested on my current project