경우에 따라 앱에서 개별 토큰을 명시적으로 취소하거나 무효화해야 합니다. 일반적인 경우는 사용자가 OAuth 지원 앱에서 로그아웃하는 경우입니다. 취소된 토큰은 더 이상 승인에 유용하지 않습니다. 토큰이 취소된 후 앱에서 API 프록시에 이 토큰을 제공하면 VerifyAccessToken 작업이 있는 OAuthV2 정책이 해당 토큰을 거부합니다.
특정 토큰을 취소하는 대신 클라이언트 ID나 전체 개발자 앱을 취소할 수 있습니다. 자세한 내용은 개발자 앱 키 취소 및 승인을 참조하세요. 개별 토큰 취소와 비교하여 클라이언트 ID나 개발자 앱을 취소하면 영향이 더욱 광범위해집니다. 클라이언트 ID나 개발자 앱을 취소하면 Apigee는 해당 클라이언트 ID나 개발자 앱과 연결된 모든 토큰을 거부하고 더 이상 해당 클라이언트 ID나 개발자 앱의 새 토큰을 발급하지 않습니다.
액세스 토큰 또는 갱신 토큰 중 하나를 취소한 후에 언제든지 만료되기 전에 토큰을 선택적으로 다시 승인할 수 있습니다. 토큰을 다시 승인하면 Apigee OAuthV2 정책에서 토큰이 만료될 때까지 해당 토큰을 다시 승인합니다. 토큰 만료는 토큰의 승인 또는 취소 상태와 관계가 없습니다.
ValidateAccessToken 작업이 있는 Apigee OAuthV2 정책은 토큰이 승인되고(또는 취소되지 않음) 만료되지 않은 경우에만 액세스 토큰을 허용합니다.
마찬가지로 RefreshAccessToken 작업이 포함된 Apigee OAuthV2 정책은 토큰이 승인되고(또는 취소되지 않음) 만료되지 않은 경우에만 갱신 토큰을 허용합니다.
OAuthV2 정책은 한 번에 단일 토큰을 취소하고 복구할 수도 있습니다. RevokeOAuthV2 정책은 앱 ID나 최종 사용자 ID를 통해 토큰 여러 개를 한 번에 취소할 수 있다는 점에서 보다 유연합니다. 이 페이지의 나머지 부분에서는 OAuthV2 정책을 사용하여 토큰을 취소하거나 이전에 취소된 토큰을 복구하는 방법을 설명합니다.
액세스 권한 및 갱신 토큰 취소
다음은 InvalidateToken 작업을 사용하는 OAuthV2 정책 구성의 예시입니다. 이 경우 Token 요소의 cascade 속성이 true이므로 Apigee에서 액세스 토큰과 관련 갱신 토큰을 모두 취소합니다.
cascade 플래그 작동 방식에 대한 자세한 내용은 토큰 요소 속성에 대한 다음 섹션을 참조하세요.
<Tokens>/<Token> 요소
취소할 토큰을 지정하는 흐름 변수를 식별합니다. 예를 들어 개발자가 access_token이라는 쿼리 매개변수를 사용하여 취소 요청을 제출할 경우 올바른 흐름 변수는 request.queryparam.access_token입니다. 예를 들어 HTTP 헤더의 토큰을 요구하려면 이 값을 request.header.access_token으로 설정합니다.
JWT 형식의 액세스 토큰을 취소할 수는 없습니다.
또한 OAuthV2 정책을 사용하여 JWT 형식의 액세스 토큰과 연결된 갱신 토큰을 취소할 수 없습니다. 여기에 지정된 컨텍스트 변수가 JWT 액세스 토큰 또는 JWT 액세스 토큰과 연결된 갱신 토큰을 참조하면 런타임 오류가 발생합니다.
RevokeOAuthV2 정책을 사용하여 JWT 액세스 토큰과 연결된 갱신 토큰을 취소할 수 있습니다.
속성
type(필수, 문자열): 지정된 변수로 식별된 토큰 유형입니다. 지원되는 값은 accesstoken 및 refreshtoken:입니다.
액세스 토큰을 취소하려면 accesstoken 유형을 지정합니다.
액세스 토큰과 갱신 토큰을 모두 취소하려면 refreshtoken 유형을 지정합니다. refreshtoken 유형이 나타나면 Apigee는 토큰이 갱신 토큰이라고 가정합니다. 갱신 토큰을 찾으면 취소됩니다. 갱신 토큰을 찾을 수 없다면 Apigee는 액세스 토큰인지 확인합니다. 액세스 토큰이 존재하는 경우 취소됩니다.
참고: 이미 무효화된 토큰을 InvalidateToken 정책에 전달하면 오류가 반환될 것으로 생각할 수도 있지만 정책은 오류를 반환하지 않습니다. 이러한 작업은 아무런 영향을 미치지 않습니다.
cascade(선택사항, 부울, 기본값: true) 이 속성의 기본 용도는 연결된 액세스 토큰을 취소하지 않고 갱신 토큰을 취소하는 것입니다. 다음 사례를 참조하세요.
갱신 토큰만 취소하고 관련 액세스 토큰은 취소하지 않습니다. 이렇게 하려면 <Token> 유형을 refreshtoken으로 설정하고 cascade를 false로 설정합니다.
액세스 토큰과 갱신 토큰을 모두 취소합니다. 이렇게 하려면 <Token> 유형을 accesstoken으로 설정합니다. cascade의 값은 true(기본값) 또는 false가 될 수 있습니다. 이를 true로 설정하면 액세스 토큰과 갱신 토큰이 모두 취소됩니다. 이를 false로 설정하면 액세스 토큰이 취소되고 갱신 토큰을 사용할 수 없게 됩니다. 자세한 설명은 아래 참고 사항을 참조하세요.
액세스 토큰을 취소하고 관련 갱신 토큰은 취소하지 않습니다. 이 작업은 지원되지 않습니다. 자세한 설명은 아래 참고 사항을 참조하세요.
참고: 보안상의 이유로 액세스 토큰을 취소하면 관련 갱신 토큰도 함께 취소됩니다. 따라서 cascade 속성을 사용하여 액세스 토큰만 취소할 수는 없습니다. 예를 들어 <Token> 유형을 accesstoken으로 설정하고 cascade=false를 설정하면 액세스 토큰이 예상대로 취소되지만 관련 갱신 토큰은 사용할 수 없습니다. 취소된 액세스 토큰을 갱신하는 데 사용될 수 없습니다. cascade 속성의 기본 사용 사례는 갱신 토큰만 취소하려는 경우입니다. 이 경우 <Token> 유형을 refreshtoken으로 설정하고 cascade=false를 설정합니다. 갱신 토큰은 취소되지만 관련 액세스 토큰은 만료되거나 취소되기 전까지 유효합니다. 자세한 내용은 커뮤니티의 포럼 토론을 참조하세요.
액세스 권한 및 갱신 토큰 승인
ValidateToken 작업을 사용하여 취소된 토큰을 '다시 승인'합니다. 즉, 이 작업을 적용하면 대상 액세스 토큰 또는 갱신 토큰의 상태가 '취소됨'에서 '승인됨'으로 변경됩니다. 취소된 토큰이 아직 만료되지 않았다면 승인할 수 있습니다.
승인할 토큰을 지정하는 흐름 변수를 식별합니다. 예를 들어 개발자가 access_token이라는 쿼리 매개변수를 사용하여 승인 요청을 제출해야 할 경우 올바른 흐름 변수는 request.queryparam.access_token입니다. 예를 들어 HTTP 헤더의 토큰을 요구하려면 이 값을 request.header.access_token으로 설정합니다.
속성
type(필수, 문자열) 지정된 변수로 식별된 토큰 유형입니다. 지원되는 값은 accesstoken 및 refreshtoken입니다.
cascade (선택사항, 부울): 기본적으로 이 옵션은 true로 설정되며 승인이 관련 토큰에도 적용되도록 만듭니다. 따라서 갱신 토큰에 적용하면 연결된 액세스 토큰도 승인됩니다. 액세스 토큰에 적용한 경우 해당 갱신 토큰도 승인됩니다. 이를 false로 설정하면 지정된 액세스 토큰 또는 갱신 토큰만 승인됩니다.
[[["이해하기 쉬움","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-08-18(UTC)"],[[["\u003cp\u003eThis documentation covers token revocation and re-approval within Apigee and Apigee hybrid, focusing on the management of OAuth tokens.\u003c/p\u003e\n"],["\u003cp\u003eTokens can be revoked using either the OAuthV2 policy with the \u003ccode\u003eInvalidateToken\u003c/code\u003e operation or the RevokeOAuthV2 policy, but only opaque OAuth tokens, not JWTs.\u003c/p\u003e\n"],["\u003cp\u003eRevoking a client ID or developer app invalidates all associated tokens and prevents the issuance of new ones, while revoking a single token only impacts that specific token.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ecascade\u003c/code\u003e attribute within the \u003ccode\u003eToken\u003c/code\u003e element allows for control over whether both the access token and refresh token are revoked or only the refresh token.\u003c/p\u003e\n"],["\u003cp\u003eRevoked tokens can be re-approved using the \u003ccode\u003eValidateToken\u003c/code\u003e operation of the OAuthV2 policy, making them valid again until they expire, and tokens are cached for 3 minutes, even after being revoked.\u003c/p\u003e\n"]]],[],null,["# Revoking and approving tokens\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nUnderstanding token revocation\n------------------------------\n\nIn some cases, apps are required to explicitly revoke or invalidate individual\ntokens. A typical case might be when a user logs out of an OAuth-enabled app. A revoked\ntoken will no longer be useful for authorization. After a token has been revoked, if an\napp presents that token to an API proxy, an OAuthV2 policy with an Operation of\nVerifyAccessToken will reject that token.\n| **Warning:**OAuth tokens are cached for three minutes (180 seconds); therefore, a revoked token may still succeed for up to three minutes, until its cache limit expires.\n\nThe standard for token revocation is defined by IETF RFC 7009, the [OAuth 2.0 Token Revocation\nspecification](https://tools.ietf.org/html/rfc7009).\n\nAs an alternative to revoking specific tokens, you can revoke client IDs, or entire developer\napps. See [Revoking\nand approving developer app keys](/apigee/docs/api-platform/security/oauth/revoking-and-approving-consumer-ids) for details. As compared to revoking an\nindividual token, revoking a client ID or developer app has a broader impact. When you\nrevoke a client ID or developer app, Apigee will reject all tokens associated with that\nclient ID or developer app, and will no longer issue new tokens for that client ID or\ndeveloper app.\n\nAfter revoking a token, either an access token or a refresh token, you can optionally\nre-approve that token, at any time before it expires. After re-approving the token, the\nApigee OAuthV2 policy will again accept that token for authorization, until the token\nexpires. Token expiration is independent of the approved or revoked state of the token.\nThe Apigee OAuthV2 policy with an Operation of ValidateAccessToken will accept an\naccess token only if that token is both approved (or not revoked) and not expired.\nLikewise, the Apigee OAuthV2 policy with an Operation of RefreshAccessToken will accept a\nrefresh token only if that token is both approved (or not revoked) and not expired.\n| **Note:** You cannot revoke a JWT access token. You can revoke only opaque OAuth tokens, either access tokens or refresh tokens, that have been generated by the OAuthV2 policy. While the OAuthV2 policy can generate access tokens that are of either opaque format or JWT format, you cannot revoke JWT access tokens that have been generated by the OAuthV2 policy.\n\nThere are two policies that you can use to revoke tokens:\n\n- the [OAuthV2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy), using an `Operation` of `InvalidateToken`.\n- the [RevokeOAuthV2 policy](/apigee/docs/api-platform/reference/policies/revoke-oauth-v2-policy).\n\nThe OAuthV2 policy has the capability to revoke, and also reinstate, a single token at\na time. The RevokeOAuthV2 policy is more flexible in that it can revoke multiple tokens at\nonce, by App ID, or End User ID. The rest of this page describes using the OAuthV2 policy\nto revoke a token or to reinstate a previously revoked token.\n\nRevoking access and refresh tokens\n----------------------------------\n\n| **Warning:**OAuth tokens are cached for three minutes (180 seconds); therefore, a revoked token may still succeed for up to three minutes, until its cache limit expires.\n\nHere's an example configuration for the OAuthV2 policy that uses the InvalidateToken\nOperation. In this case, because the `cascade` attribute on the\n`Token` element is true, Apigee revokes both the access token and its\nassociated refresh token. \n\n```carbon\n \u003cOAuthV2 name=\"InvalidateToken\"\u003e\n \u003cOperation\u003eInvalidateToken\u003c/Operation\u003e\n \u003cTokens\u003e\n \u003cToken type=\"accesstoken\" cascade=\"true\"\u003erequest.queryparam.token\u003c/Token\u003e\n \u003c/Tokens\u003e\n \u003c/OAuthV2\u003e\n \n```\n\nFor more information about how the cascade flag works, see the section below on the\nAttributes for the Token element.\n\n### \\\u003cTokens\\\u003e/\\\u003cToken\\\u003e\nelement\n\nIdentifies the flow variable that specifies the token to be revoked. If developers are\nexpected to submit a revocation request using a query parameter\nnamed `access_token`, for example, the correct flow variable will\nbe: `request.queryparam.access_token`. To require the token in an HTTP header,\nfor example, set this value to `request.header.access_token`.\n\nIt is not possible to revoke an access token that is in JWT format.\nFurther, it is not possible to use the OAuthV2 policy to\nrevoke a refresh token that is associated to an access token that is in JWT\nformat. A runtime error will occur if the context variable specified here refers to\na JWT access token, or a refresh token that is associated to a JWT access token.\nYou can revoke refresh tokens associated to JWT access tokens using the [RevokeOAuthV2 policy](/apigee/docs/api-platform/reference/policies/revoke-oauth-v2-policy).\n\n### Attributes\n\n- `type` (required, string): The token type identified by the variable specified. Supported values are `accesstoken` and `refreshtoken:`\n - To revoke an access token, specify type accesstoken.\n - To revoke both the access and refresh tokens, specify type refreshtoken. When it sees type refreshtoken, Apigee assumes the token is a refresh token. If that refresh token is found, then it is revoked. If that refresh token is not found, then Apigee checks to see if it is an access token. If the access token exists, then it is revoked. \n\n **Note:** If you pass an already invalidated token to an InvalidateToken policy, the policy doesn't return an error, although you might expect it to. Such an operation has no effect.\n- `cascade` (optional, boolean, default: true) The primary use of this attribute is to revoke a refresh token without revoking its associated access token. Consider these cases:\n - Revoke a refresh token only and do not revoke its associated access token. To do this, set the \\\u003cToken\\\u003e type to `refreshtoken` and set cascade to `false`.\n - Revoke both the access token and the refresh token. To do this, set the \\\u003cToken\\\u003e type to `accesstoken`. The value of cascade can be either `true` (the default) or `false`. If you set it to `true`, then both the access token and the refresh token are revoked. If you set it to `false`, the access token is revoked, and the refresh token is unusable. See the Note below for more explanation.\n - Revoke an access token and do not revoke its associated refresh token. Not supported. See the Note below for more explanation.\n\n**Note:** For security reasons, if you revoke an\naccess token, the associated refresh token will be revoked also. Therefore, you cannot use\nthe cascade attribute to revoke only an access token. For example, if you set the \\\u003cToken\\\u003e\ntype to `accesstoken`, and set `cascade=false`, the access token is revoked\n(as expected); however, the associated refresh token is unusable. It cannot be used to refresh\nthe revoked access token. The primary use case for the cascade attribute is when you want to only\nrevoke a refresh token. In that case, set the \\\u003cToken\\\u003e type to `refreshtoken`,\nand set `cascade=false`. The refresh token will be revoked, but its associated access\ntoken will remain valid (until it expires or is revoked). For more information, see this [Community forum discussion](https://community.apigee.com/questions/5813/need-help-interpreting-cascade-on-invalidatetoken.html#comment-6763).\n\nApproving access and refresh tokens\n-----------------------------------\n\nUse the ValidateToken operation to \"re-approve\" a revoked token. That is, when you apply this\noperation, the status of the targeted access or refresh token is changed from 'revoked' to\n'approved'. You can validate any revoked token that has not already expired. \n\n```gdscript\n\u003cOAuthV2 name=\"ValidateToken\"\u003e\n \u003cOperation\u003eValidateToken\u003c/Operation\u003e\n \u003cTokens\u003e\n \u003cToken type=\"refreshtoken\" cascade=\"true\"\u003eflow.variable\u003c/Token\u003e\n \u003c/Tokens\u003e\n\u003c/OAuthV2\u003e\n```\n\n### \\\u003cTokens\\\u003e/\\\u003cToken\\\u003e\nelement\n\nIdentifies the flow variable that specifies the token to be validated. If developers are\nexpected to submit a validation request using a query parameter\nnamed `access_token`, for example, the correct flow variable will\nbe: `request.queryparam.access_token`. To require the token in an HTTP header,\nfor example, set this value to `request.header.access_token`.\n\n### Attributes\n\n- `type` (required, string) The token type identified by the variable specified. Supported values are `accesstoken` and `refreshtoken`.\n- `cascade` (optional, boolean): By default, this option is set to `true`, and causes the validation to propagate to associated tokens. So, if applied to a refresh token, its associated access token is also validated. If applied to an access token, its associated refresh token is also validated. If you set this to `false`, then only the specified access or refresh token is validated."]]
