Antipattern: Set a long expiration time for OAuth tokens

Apigee Edge provides the OAuth 2.0 framework to secure APIs. OAuth2 is one of the most popular open-standard, token-based authentication and authorization schemes. It enables client applications to access APIs on behalf of users without requiring users to divulge their username and password.

Apigee Edge allows developers to generate access and/or refresh tokens by implementing any one of the four OAuth2 grant types - client credentials, password, implicit, and authorization code - using the OAuthv2 policy. Client applications use access tokens to consume secure APIs. Each access token has its own expiry time, which can be set in the OAuthv2 policy.

Refresh tokens are optionally issued along with access tokens with some of the grant types. Refresh tokens are used to obtain new, valid access tokens after the original access token has expired or been revoked. The expiry time for refresh tokens can also be set in the OAuthv2 policy.


Setting a long expiration time for an access token and/or refresh token in the OAuthv2 policy leads to accumulation of OAuth tokens and increased disk space use on Cassandra nodes.

The following example OAuthV2 policy shows a long expiration time of 200 days for refresh tokens:

<OAuthV2 name="GenerateAccessToken">
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
    <GenerateResponse enabled="true"/>

In the above example:

  • The access token is set with a reasonably lower expiration time of 30 mins.
  • The refresh token is set with a very long expiration time of 200 days.
  • If the traffic to this API is 10 requests/second, then it can generate as many as 864,000 tokens in a day.
  • Since the refresh tokens expire only after 200 days, they persist in the data store (Cassandra) for a long time leading to continuous accumulation.


  • Leads to significant growth of disk space usage on the data store (Cassandra).
  • For Private Cloud users, this could increase storage costs, or in the worst case, the disk could become full and lead to runtime errors or an outage.

Best Practice

Use an appropriate lower expiration time for OAuth access and refresh tokens depending on your specific security requirements, so that they get purged quickly and thereby avoid accumulation.

Set the expiration time for refresh tokens in such a way that it is valid for a little longer period than the access tokens. For example, if you set 30 minutes for access token and then set 60 minutes for refresh token.

This ensures that:

  • There's ample time to use a refresh token to generate new access and refresh tokens after the access token is expired.
  • The refresh tokens will expire a little while later and can get purged in a timely manner to avoid accumulation.

Further reading