Setting different expire time for access token depending on product or proxy

Not applicable

Hi,

We have a few API proxies. When we first started, we added a "/token" endpoint to each one of our API proxies. We were just learning Apigee and oAuth. Now that we know a bit more about our use case and needs, we are setting up a standalone /oauth2 proxy that we'll use for client_credentials and authorization_code grant types.

The main issue that we have with using a central apigee proxy is that for some use cases where the data is public, not very sensitive and the application runs on trusted servers we have the need to have a longer time to live for the access token before it expires. There are other use cases where we are dealing with more protected and sensitive data and the access token is only valid for less than a couple of minutes.

What suggestions do you have for programmatically setting the expiration time of access tokens? I was thinking about using Apigee kvm to store a default time to live for access tokens and define api proxies and the expiration of tokens in milliseconds. The /oauth2/token endpoint could then read the kvm and use that value for the token expiration. Another approach could be that we would have an API (that we call via a service callout) that returns in milliseconds the timeout to use for the access token.

Within an Apigee Proxy is it possible to figure out the application name or proxies registered for a given pair of client id & secret? For people with a similar scenario, what approach have you used to set different access token expiration values?

Solved Solved
1 9 5,473
1 ACCEPTED SOLUTION

Hi @jose.cedeno

You could probably use Custom attributes that are available for Dev apps and products. As a service provider, if you want to control the ttl, then it would be better to set the ttl as a custom attribute in the Product configurations. So in your use case, you will have two categories of products - public and protected. You can configure the ttl accordingly and the dev apps that uses these products will use these attributes at runtime.

For example, in the screenshot below, I have a Product defined with a custom attribute (see bottom of the screenshot)

4292-screenshot-2017-02-02-at-114233.png

You need to include your Oauth proxy to this product as well. Once that is done, when you have a valid client_id (from the dev app that uses this product) and after running the VerifyApiKey on your Oauth token flow, you should be able to get the custom attributes as flow variables.

In this case., the above custom attribute will be verifyapikey.{policy_name}.apiproduct.tokenTtl. With this flow variable, you can set that in the Oauth policy that creates the token with the ExpiresIn attribute.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn ref="verifyapikey.Verify-API-Key.apiproduct.tokenTtl">3600000</ExpiresIn><!--default value in milliseconds if flow variable is null-->
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

By doing this, you have complete control of changing them which is real time as well. More info here on policy docs and more posts here on Custom attributes

Custom attributes is the answer for your questions you asked at the very end as well.

Hope this was useful. Please reach out if you still have questions. Happy to help

View solution in original post

9 REPLIES 9

Hi @jose.cedeno

You could probably use Custom attributes that are available for Dev apps and products. As a service provider, if you want to control the ttl, then it would be better to set the ttl as a custom attribute in the Product configurations. So in your use case, you will have two categories of products - public and protected. You can configure the ttl accordingly and the dev apps that uses these products will use these attributes at runtime.

For example, in the screenshot below, I have a Product defined with a custom attribute (see bottom of the screenshot)

4292-screenshot-2017-02-02-at-114233.png

You need to include your Oauth proxy to this product as well. Once that is done, when you have a valid client_id (from the dev app that uses this product) and after running the VerifyApiKey on your Oauth token flow, you should be able to get the custom attributes as flow variables.

In this case., the above custom attribute will be verifyapikey.{policy_name}.apiproduct.tokenTtl. With this flow variable, you can set that in the Oauth policy that creates the token with the ExpiresIn attribute.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn ref="verifyapikey.Verify-API-Key.apiproduct.tokenTtl">3600000</ExpiresIn><!--default value in milliseconds if flow variable is null-->
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

By doing this, you have complete control of changing them which is real time as well. More info here on policy docs and more posts here on Custom attributes

Custom attributes is the answer for your questions you asked at the very end as well.

Hope this was useful. Please reach out if you still have questions. Happy to help

Thank you for the detail in the answer. I hadn't thought about using the custom attributes, but after reading your post I agree it's the way to go.

Cool !! Please reach out if you need any info.

We recently got a bit of time to set this up and it worked as expected. The only tricky thing at first was realizing that we had to use the Verify-API-Key policy to be able to access the product flow variables. It wasn't intuitive to use the verify api key policy before you generate the access tokens, but it works 🙂 .

Thanks again!

Great answer, Sai ! I wish I could upvote more!

+1 @Sai Saran Vaidyanathan , Great Answer

GREAT question.

I can understand its been closed long back, but would like to raise the issue which I am facing. I have followed the same steps and able to see the custom expiry time in the lower environment. But, same configuration if I am using in higher environments, it is not working as expected. When I am using 600000 (ms) as the token-ttl, still 559ms is coming while generating the access token? where can I check and how 559ms is configured? any help would be appreciated.

but would like to raise the issue which I am facing.

Please ask a new question. Thank you.