Refresh tokens are used to obtain new access tokens after the original access
token has expired or been revoked. Refresh tokens are optionally issued along
with access tokens with some of the grant types.
Antipattern
Refresh tokens can be issued either by Apigee or via external resources.
However, this is an antipattern if the refresh token is never used via the
RefreshAccessToken operation.
Impact
Persisting refresh tokens unnecessarily negatively impacts both performance
and reliability of the authentication system.
Best practice
If the refresh token is never needed
If refresh tokens are not needed, developers should use the 'client
credentials' or 'implicit' grant types when generating new access tokens.
These grant types do not issue refresh tokens, which is desirable if the
refresh token functionality is not required.
If the proxy performs only read operation with refresh tokens
Apigee offers
GetOAuthV2Info which can be used to retrieve refresh token
attributes. Developers should not use this policy to validate refresh tokens.
It is an antipattern that the refresh token is never used to exchange for a
new access token. Note that Apigee can work with
external access and refresh tokens. If the refresh token flow happens
outside of Apigee, it's highly recommended to use the RefreshAccessToken
operation such that any imported refresh tokens no longer valid are properly
removed from the Apigee system.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[],[],null,["# Antipattern: Issuing refresh tokens without invoking refresh flow\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/issuing-refresh-tokens) documentation.*\n\n\nRefresh tokens are used to obtain new access tokens after the original access\ntoken has expired or been revoked. Refresh tokens are optionally issued along\nwith access tokens with some of the grant types.\n\nAntipattern\n-----------\n\n\nRefresh tokens can be issued either by Apigee or via external resources.\nHowever, this is an antipattern if the refresh token is never used via the\nRefreshAccessToken operation.\n\nImpact\n------\n\n\nPersisting refresh tokens unnecessarily negatively impacts both performance\nand reliability of the authentication system.\n\nBest practice\n-------------\n\n### If the refresh token is never needed\n\n\nIf refresh tokens are not needed, developers should use the 'client\ncredentials' or 'implicit' grant types when generating new access tokens.\nThese grant types do not issue refresh tokens, which is desirable if the\nrefresh token functionality is not required.\n\n### If the proxy performs only read operation with refresh tokens\n\n\nApigee offers\n[GetOAuthV2Info](https://cloud.google.com/apigee/docs/api-platform/reference/policies/get-oauth-v2-info-policy#refresh-token) which can be used to retrieve refresh token\nattributes. Developers should not use this policy to validate refresh tokens.\nIt is an antipattern that the refresh token is never used to exchange for a\nnew access token. Note that Apigee can work with\n[external access and refresh tokens](/apigee/docs/api-platform/security/oauth/use-third-party-oauth-system). If the refresh token flow happens\noutside of Apigee, it's highly recommended to use the RefreshAccessToken\noperation such that any imported refresh tokens no longer valid are properly\nremoved from the Apigee system.\n\nFurther reading\n---------------\n\n[Refreshing an access token](/apigee/docs/api-platform/security/oauth/access-tokens#refreshinganaccesstoken)"]]
