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>

[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>

[muthukkannan · Accepted solution]

Hi Dino,

Again, thanks a lot for the response.  The usage is same (I had picked it from your devjam repository :-)).  A bit strange. It is working now, the same revision.  The scope values in API Product was the last change that I did; I had used space as delimiter, changed it to ',' and tested it yesterday.  May be that change took time to reflect - not sure.Yesterdays' trace logTodays' trace log

[dchiesa1]

YES

Oh a little bitter+sweet, eh?   It's working, which is great!  😁 But you made no changes, which is confounding.  😤

It is a good possibility that the cache had an effect on what you observed. The API Product and App information IS CACHED in the runtime. When you change it via the administrative UI (cloud console), the changes will not be available instantly in the runtime.  I believe the cache TTL is 180 seconds, but not certain of this, in this scenario.

Anyway I'm glad it's working for you.