Changing scope attributes associated with access token

Google Cloud Apigee
1

We have a requirement to associate the attributes and scope parameters with the access token. Currently, we are doing it using the management API call like below.

https://api.enterprise.apigee.com/v1/organizations/{org_name}/oauth2/accesstokens/{access_token**}

Request Headers:
Content-Type : application/json
Payload :
{
“attributes” : [
{
“name” : “{attribute_name1}”,
“value” : “{value1}”
},
{
“name” : “{attribute_name2}”,
“value” : “{value2}”
}
],
“scope” : “read”
}

We want to avoid use of management API call in service callout. Is there any OOB policy which enables to set scope parameter as well as the attributes. I checked with SetOAuthv2 , But I found from Apigee documentation that this policy can be used to add/remove/update custom attributes. This policy can not be used to change fields like scope, status, expires_in, developer_email, client_id, org_name, or refresh_count.

Can anyone provide a better option than calling management API call.?

1 Like
2

@Varun Singh do you want to continue using the same access token but have it with different scopes? Don’t know of any OOTB way of doing this without Management API calls.

An option would be to mine a new access token with changed scopes and use this going forward.

I don’t know if it is a good idea from a user experience point of view to be able to easily change the scopes of an already mined token. Especially in the case of user authenticated OAuth flows where the user has given a consent to use specific scopes. It might not be right to change the scopes (esp increase the scopes) without taking the user through a consent flow again.

In case of machine authenticated flows, the app / server could very easily just request for a new access token with the right scopes.

1 Like
3

Hi @Varun Singh You can associate Custom attributes & scope to tokens while generating them in Edge.

Custom Attributes
You can include the attributes into your token by specifying them under section in GenerateAccessToken policy as indicated below -

<OAuthV2 name="GenerateAccessToken">
  <Operation>GenerateAccessToken
  </Operation>
  <ExpiresIn>1000</ExpiresIn>
  <GenerateResponse />
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <Attributes> 
    <Attribute name="user-agent" ref="request.header.user-agent" display="false"></Attribute>
<Attribute name="custom-attr" ref="request.queryparam.abc" display="false"></Attribute>
  </Attributes>
</OAuthV2>

Please see this page for more details on customising the token. Once the token is generated you get or set token properties using the Get or Set OAuth V2 Info policy. You can also do this with the management API calls.

Scope
When Edge generates an access token, it may assign a scope to that token. The scope is determined based on the Product(s) the app is associated to.

3248-product-scope.jpg
3248-product-scope.jpg1208×962 138 KB

However when a client app requests an access token from Apigee Edge, it can optionally specify which scopes it would like to have associated with that token.

For example, the following request asks for the scope “READ”. That is, the client is asking that the authorization server (Edge) generate an access token that has scope “READ” (giving the app authorization to call APIs that have scope “READ”). The app sends a POST request like this:

curl -i -X POST -H Authorization: Basic Mg12YTk2UkEIyIBCrtro1QpIG -H content-type:application/x-www-form-urlencoded [http://myorg-test.apigee.net/oauth/token?grant_type=client_credentials&scope=READ](http://myorg-test.apigee.net/oauth/token?grant_type=client_credentials&scope=READ)

When Edge receives this request it knows which app is making the request and it knows which developer app the client registered (the client ID and client secret keys are encoded in the basic auth header). Because the scope query parameter is included, Edge needs to decide if any of the API products associated with the developer app have scope “READ”. If they do, then an access token is generated with scope “READ”.

What if the client does not attach a scope parameter? In this case, Edge generates a token that includes all of the scopes recognized by the developer app. It’s important to understand that the default behavior is to return an access token that contains the union of all scopes for all of the products included in the developer app. The page here has additional details on working with Scopes.

AFIAK once generated the scope attribute can’t be changed with Set OAuth V2 or via management API. However you can ask for a different scope on the refresh token call.

Hope this helps!

4

Thanks Prashanth for the information.We have a requirement to update the scope after making backend call

We can think of invalidating the access token after backend call.

Thanks,

Varun

5

Thanks @Sudheendra for the information.

6

@Varun Singh,

I feel the alternate way to do this is to store the “scope” as a custom attribute additionally and use it specifically in the flow for validation purpose.

If we do so, then you can actually use setOAuthV2Info policy to set the value of the scope as per your need (after the generation of the token). Following is an example, where we are setting the value of scope from context variable RequestedScope to a token custom attribute RequestedScope.

<SetOAuthV2Info name="Modify.AccessToken"> 
  <AccessToken ref="apigee.access_token"></AccessToken>
  <Attributes>
	<Attribute name="RequestedScope" ref="RequestedScope" display="false"/>
  </Attributes>
</SetOAuthV2Info>
7

Thanks @MEGHDEEP BASU for your response. But our requirement is somewhat different. Requirement is to update the scope associated with the access token and not to store the scope as attribute. :slight_smile:

Thanks,

Varun