Apigee는 API를 보호하기 위해 OAuth 2.0 토큰 기반 인증을 구현할 수 있는 도구 및 정책 집합을 제공합니다. IETF RFC 6749에 설명된 OAuth2는 API에 대한 인증 및 승인을 위해 가장 널리 지원되는 개방형 표준입니다. 클라이언트 애플리케이션이 API 구현에 전송하는 표준 형식 사용자 인증 정보로 토큰을 설정합니다. API 구현은 토큰을 확인하여 클라이언트가 API에 액세스할 권한이 있는지 확인할 수 있습니다.
Apigee를 사용하면 개발자는 OAuthv2 정책을 사용하는 4가지 OAuth2 부여 유형인 클라이언트 사용자 인증 정보, 비밀번호, 암시적 인증 및 인증 코드 중 한 가지를 구현하여 액세스 토큰이나 갱신 토큰을 생성할 수 있습니다. 또한 API 개발자는 Apigee를 사용하여 IETF RFC 8693에 설명된 대로 토큰 교환 패턴을 따르는 권한 부여를 비롯한 커스텀 권한 부여를 구현할 수 있습니다.
클라이언트 애플리케이션은 액세스 토큰을 사용하여 보안 API를 소비합니다. 각 액세스 토큰에는 고유한 만료 시간이 있으며, 이는 OAuthv2 정책에서 설정할 수 있습니다.
Apigee는 일부 부여 유형에서 액세스 토큰과 함께 갱신 토큰을 선택적으로 생성하고 반환할 수 있습니다. 클라이언트는 갱신 토큰을 사용하여 원본 액세스 토큰이 취소되거나 만료된 후 새 액세스 토큰을 획득합니다. 갱신 토큰의 만료 시간은 OAuthv2 정책에서도 설정할 수 있습니다.
안티패턴
OAuthv2 정책에서 액세스 토큰 또는 갱신 토큰의 만료 시간을 길게 설정하면 토큰 유출이 발생할 경우 취약점이 확대되어 보안 위험을 초래할 수 있습니다. 또한 영구 스토리지에 OAuth 토큰이 누적되어 시간이 지남에 따라 성능이 저하될 수 있습니다.
예 1
다음 OAuthV2 정책 예시는 10일이라는 긴 만료 시간이 지정된 액세스 토큰을 보여줍니다.
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>864000000</ExpiresIn> <!-- 10 days -->
<RefreshTokenExpiresIn>864000000</RefreshTokenExpiresIn> <!-- 10 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>
위의 예시에서,
액세스 토큰의 수명은 10일로 설정됩니다.
갱신 토큰 수명도 10일로 설정됩니다.
영향
수명이 긴 액세스 토큰은 보안 위험을 나타냅니다. 토큰이 유출되거나 손실된 경우 수명이 짧은 토큰은 자연스럽게 만료되어 쓸모없게 되지만 수명이 긴 토큰은 잠재적으로 더 긴 기간 동안 API에 대한 액세스 권한을 계속 부여하여 취약점이 노출될 수 있는 기간을 늘립니다.
액세스 토큰의 수명은 짧아야 하며(30분 이하) 그 수명은 갱신 토큰의 수명보다 훨씬 짧아야 합니다.
예 2
다음 OAuthV2 정책 예시는 200일이라는 긴 만료 시간이 지정된 갱신 토큰을 보여줍니다.
이 API에 대한 트래픽이 초당 10개 요청이면 하루에 최대 864,000개의 토큰을 생성할 수 있습니다.
갱신 토큰은 200일 후에 만료되므로 전체 수명 동안 데이터 스토어에 누적됩니다.
영향
데이터 스토어에 많은 수의 토큰이 누적되므로 갱신 토큰 수명이 길어지면 시간이 지남에 따라 성능이 저하될 수 있습니다. Apigee Hybrid에서는 과도한 토큰 누적이 지속성 계층의 디스크 공간 소진에 기여할 수도 있습니다.
권장사항
자신에게 맞는 특정한 보안 요구사항에 따라 OAuth 액세스 및 갱신 토큰에 적절한 만료 시간을 사용하여 유출된 토큰의 취약점 기간을 줄이고 데이터 저장소에 토큰이 누적되지 않게 합니다. 액세스 토큰 수명은 30분, 갱신 토큰 수명은 24시간으로 시작하는 것이 좋습니다.
갱신 토큰의 만료 시간을 액세스 토큰의 전체 기간의 배수로 설정합니다. 예를 들어 액세스 토큰에 대해 30분을 설정한 후 갱신 토큰의 전체 기간을 24시간 또는 7일 등 지원해야 하는 사용자 환경에 적합한 시간으로 설정합니다.
[[["이해하기 쉬움","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(UTC)"],[[["\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)"]]
