GenerateAccessToken with Scope parameter for ClientCredentials is not reflected in the Token

[muthukkannan]

Hi,

I see a similar a question raised in 2021, but that seem to be have been resolved, since it was a problem in variable referencing (referring to query param instead of form param).  In the response it was stated scope has to be added during auth-code generation for it to reflect in AccessToken.  

In our requirement, I would like to use client_credentials grant_type; no auth-code flow.  But would like to provide the option of restricting the scopes for generated tokens, to the client application.  There is an optional parameter <Scope> in the policy.  The API Product has the required scopes that are being set in the policy.  Still the generated access token shows Scope as "".   Should I be using a custom attribute for setting the scope and a custom implementation during verifyAccessToken to validate the scope, is that only option for this case?  am I missing something?

Thanks & Regards,

Muthu

[dchiesa1 · Accepted solution]

Hi Muthu

am I missing something?

I think so.

The OAuthV2 policy is a multi-purpose policy, and configuring it can get complicated. But it WILL work if you configure everything properly.

Configure GenerateAccessToken like this:

<OAuthV2 name="OAuthV2-GenerateAccessToken-CC">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn ref="request.queryparam.lifetimems">1800000</ExpiresIn>
  <RefreshTokenExpiresIn>691200000</RefreshTokenExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.formparam.grant_type</GrantType>
  <Scope>request.formparam.scope</Scope>
  <GenerateResponse enabled="true"/>
</OAuthV2>

The text inside the Scope element is a variable name. It's not the actual desired scope. In my case I am using the form parameter named "scope" therefore the variable name I use is request.formparam.scope . The client request for such a token will be like this:

curl -i -u $CLIENTID:$CLIENTSECRET $endpoint/oauth2-cc/token -d 'scope=READ' -d 'grant_type=client_credentials' 

When this happens, the token dispensing proxy will generate a token with READ scope. Further assumptions here are:

1. The CLIENTID and CLIENTSECRET are good, valid, matching, and not revoked.
2. The CLIENTID is authorized for a specific Product, which has on its list of scopes, at least READ

Take care: at one point there was a bug/gotcha in the API Product UI. The UI asks for a "comma separated list". If you specified a list that included SPACES, then the scope would include the space. and so specifying "READ , UPDATE , WRITE" might not work the way you would like it to work. I filed a bug a while ago to ask that the UI trim the spaces from whatever is specified in the list, but I don't know if that bug has been addressed, and I haven't tested it.

OK, let's assume that all the configuration is correct as described above. If the client does not pass that scope form parameter, the policy will succeed in generating a token, but with no scope. Suppose you have an API Product with Scopes = READ,UPDATE,WRITE, just as shown above. If, within the Scope element inside the policy configuration for OAuth2/GenerateAccessToken, you specify a word like READ , then at runtime, the policy will try to de-reference the variable named READ ! It will find nothing (probably) , and it will then generate a token with no scope.

Verifying a token with scope is different - you must not specify a variable within the Scope element; instead you specify the hard-coded scope. So the corresponding Verify looks like this:

<OAuthV2 name='OA-Verify-Token-READ-Scope'>
    <Operation>VerifyAccessToken</Operation>
    <!-- by default, pulls token from Authorization header as per OAuthV2.0 spec -->
    <Scope>READ</Scope>
</OAuthV2>