[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eApigee uses OAuth 2.0, the widely supported open standard for API authentication and authorization, which utilizes tokens as credentials for client applications.\u003c/p\u003e\n"],["\u003cp\u003eApigee supports the generation of access and refresh tokens through various OAuth2 grant types, including client credentials, password, implicit, and authorization code, using the OAuthv2 policy.\u003c/p\u003e\n"],["\u003cp\u003eSetting long expiration times for access or refresh tokens in the OAuthv2 policy increases security risks due to an extended vulnerability window in case of token leakage or loss.\u003c/p\u003e\n"],["\u003cp\u003eLong refresh token lifetimes can lead to performance degradation and disk space issues due to the accumulation of tokens in the data store, especially in Apigee hybrid environments.\u003c/p\u003e\n"],["\u003cp\u003eBest practices suggest setting access token lifetimes to around 30 minutes and refresh token lifetimes to 24 hours, adjusting according to specific security needs and ensuring refresh token lifetimes are multiples of access token lifetimes.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Set a long expiration time for OAuth tokens\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration) documentation.*\n\n\nApigee provides a set of tools and policies that allow you to implement\n[OAuth 2.0 token-based authentication](/apigee/docs/api-platform/security/oauth/oauth-home)\nto secure your APIs. OAuth2, described in [IETF RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html), is the most widely supported open standard for authentication and\nauthorization for APIs. It establishes the *token* as a standard format credential\nthat client applications send to API implementations. The API implementation can verify the token\nto determine whether the client is authorized to access the API.\n\n\nApigee allows developers to generate access and/or refresh tokens by implementing any one of\nthe four OAuth2 grant types -\n[client credentials](/apigee/docs/api-platform/security/oauth/oauth-20-client-credentials-grant-type),\n[password](/apigee/docs/api-platform/security/oauth/implementing-password-grant-type),\n[implicit](/apigee/docs/api-platform/security/oauth/access-tokens#requestinganaccesstokenimplicitgranttype), and\n[authorization code](/apigee/docs/api-platform/security/oauth/oauth-v2-policy-authorization-code-grant-type)\n- using the [OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy). In addition, API developers can use Apigee to implement custom\ngrants, including grants following the Token Exchange pattern, as described in [IETF RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693).\nClient applications then use access tokens to consume secure APIs. Each access token has its own expiry\ntime, which can be set in the [OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy).\n\n\nApigee can optionally generate and return a refresh token along with the access token with some of the\ngrant types. A client uses a refresh token to obtain a new access token after the original access\ntoken is revoked or expires. The expiry time for the refresh token can also be set in the\n[OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy).\n\nAntipattern\n-----------\n\n\nSetting a long expiration time for an access token or a refresh token in the [OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy)\nleads to an expanded window of vulnerability in case of token leakage, which represents a\nsecurity risk. It also can lead to an accumulation of OAuth tokens in the persistent store,\nwhich can result in declining performance over time.\n\n### Example 1\n\n\nThe following example OAuthV2 policy shows a long expiration time of 10 days for the access tokens: \n\n```scdoc\n\u003cOAuthV2 name=\"OAuth-GenerateAccessToken\"\u003e\n \u003cOperation\u003eGenerateAccessToken\u003c/Operation\u003e\n \u003cExpiresIn\u003e864000000\u003c/ExpiresIn\u003e \u003c!-- 10 days --\u003e\n \u003cRefreshTokenExpiresIn\u003e864000000\u003c/RefreshTokenExpiresIn\u003e \u003c!-- 10 days --\u003e\n \u003cSupportedGrantTypes\u003e\n \u003cGrantType\u003eauthorization_code\u003c/GrantType\u003e\n \u003c/SupportedGrantTypes\u003e\n \u003cGenerateResponse enabled=\"true\"/\u003e\n\u003c/OAuthV2\u003e\n```\n\nIn the above example:\n\n- The access token lifetime is set to 10 days.\n- The refresh token lifetime is also set to 10 days.\n\n#### Impact\n\nLong-lived access tokens represent a security risk. In the event of token leakage or loss,\na short-lived token will naturally expire and become useless, while a long-lived token will\ncontinue to grant access to the API for a potentially extended period of time, increasing the\nwindow of vulnerability.\n\nAn access token should have a short lifetime, probably around 30 minutes or less, and that\nlifetime should be substantially shorter than the lifetime of the refresh token.\n\n### Example 2\n\n\nThe following example OAuthV2 policy shows a long expiration time of 200 days for refresh tokens: \n\n```scdoc\n\u003cOAuthV2 name=\"OAuth-GenerateAccessToken\"\u003e\n \u003cOperation\u003eGenerateAccessToken\u003c/Operation\u003e\n \u003cExpiresIn\u003e1800000\u003c/ExpiresIn\u003e \u003c!-- 30 minutes --\u003e\n \u003cRefreshTokenExpiresIn\u003e17280000000\u003c/RefreshTokenExpiresIn\u003e \u003c!-- 200 days --\u003e\n \u003cSupportedGrantTypes\u003e\n \u003cGrantType\u003eauthorization_code\u003c/GrantType\u003e\n \u003c/SupportedGrantTypes\u003e\n \u003cGenerateResponse enabled=\"true\"/\u003e\n\u003c/OAuthV2\u003e\n```\n\nIn the above example:\n\n- The access token is set with a reasonable and short expiration time of 30 minutes.\n- The refresh token is set with a very long expiration time of 200 days.\n- If the traffic to this API is 10 requests/second, then it can generate as many as 864,000 tokens in a day.\n- Refresh tokens expire after 200 days; they will accumulate in the data store for the entire lifetime.\n\n#### Impact\n\nExtended refresh token lifetime can potentially lead to performance degradation over time,\nas a large number of tokens will accumulate in the data store. In Apigee hybrid, excessive\ntoken accumulation may also contribute to disk space exhaustion in the persistence layer.\n\nBest practice\n-------------\n\n\nUse an expiration time for OAuth access and refresh tokens that is appropriate for your specific\nsecurity requirements, to reduce the window of vulnerability for leaked tokens and avoid token\naccumulation in the data store. A good starting\npoint for access token lifetime is 30 minutes; for refresh token lifetime, start with 24 hours.\n\n\nSet the expiration time for refresh tokens in such a way that it is valid for a multiple of\nthe lifetime of the access tokens. For example, if you set 30 minutes for access token,\nthen set the lifetime of the refresh token to be 24 hours, or 7 days, or whatever is appropriate\nfor the user experience you need to support.\n\nFurther reading\n---------------\n\n- [OAuth 2.0 framework](/apigee/docs/api-platform/security/oauth/oauth-home)\n- [Secure an API with OAuth](/apigee/docs/api-platform/tutorials/secure-calls-your-api-through-oauth-20-client-credentials)\n- [Apigee product limits](/apigee/docs/api-platform/reference/limits)"]]
