87 lines
11 KiB
Markdown
87 lines
11 KiB
Markdown
---
|
|
title: official-doc / RFC 7009 — OAuth 2.0 Token Revocation
|
|
source_type: official-doc
|
|
url: https://datatracker.ietf.org/doc/html/rfc7009
|
|
archive_url:
|
|
related_branches: [feature-keycloak-refresh-rotation-and-logout, feature-keycloak-refresh-token-rotation]
|
|
related_projects: [keycloak-patterns]
|
|
tags: [official-doc, keycloak-patterns, auth, ietf, keycloak, jwt-validation]
|
|
created: 2026-07-18
|
|
---
|
|
|
|
# RFC 7009 — OAuth 2.0 Token Revocation
|
|
|
|
> Layer: `raw/` — 외부 자료(공식 문서)의 **원문 발췌·출처 기록**.
|
|
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 `source-summary-template` 형식으로 별도 작성. 원본은 raw에 영구 보관.
|
|
|
|
## Parent / 활용 branch
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-keycloak-refresh-rotation-and-logout]] | **D4** — "명시적 revoke + logout 분리 학습". `POST /realms/<realm>/protocol/openid-connect/revoke` 호출로 refresh token 을 명시적으로 무효화하는 것의 표준 근거(요청 파라미터·응답 계약) + branch 의 "stateless JWT trap"(access token revoke 즉시 적용 안 됨) 시연의 표준 원인 설명 |
|
|
| [[raw/branch-notes/feature-keycloak-refresh-token-rotation]] | **D2** (access token revocation 즉시성을 짧은 TTL 로 해결, introspection 은 stateless 이점 상실로 비권장) + **D4** (rotation flow 중 revoke endpoint 사용) — 이 branch 의 Decision Evidence Map 과 Claims To Verify 표가 명시적으로 "RFC 7009 raw source 부재"를 Open Risk 로 지목했던 항목의 근거 자료 |
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://datatracker.ietf.org/doc/html/rfc7009
|
|
- 아카이브 URL: (미확보)
|
|
- 저자 / 조직: IETF — T. Lodderstedt, S. Dronia, M. Scurtescu (OAuth Working Group), Standards Track RFC
|
|
- 발행일: 2013-08
|
|
- 마지막 확인일: 2026-07-18
|
|
|
|
## 왜 저장했는지 / Why archived
|
|
|
|
두 keycloak-patterns branch(P3A `feature-keycloak-refresh-rotation-and-logout`, P2A `feature-keycloak-refresh-token-rotation`)가 공통으로 `/protocol/openid-connect/revoke` 호출을 다루면서도, 이 엔드포인트의 표준 근거(RFC 7009)를 Sources 에 아직 등록하지 못한 상태였다. 특히 "access token 은 revoke 직후에도 만료 전까지 유효하다"는 branch 들의 핵심 함정(stateless JWT trap)이 RFC 자체의 Implementation Note(§3)에서 명시적으로 설명되는 구조적 이유임을 확인하기 위해 저장.
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§2] "The client requests the revocation of a particular token by making an HTTP POST request to the token revocation endpoint URL."
|
|
|
|
> [§2.1] "token REQUIRED. The token that the client wants to get revoked."
|
|
|
|
> [§2.1] "token_type_hint OPTIONAL. A hint about the type of the token submitted for revocation. Clients MAY pass this parameter in order to help the authorization server to optimize the token lookup."
|
|
|
|
> [§2.1] "If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens" [...] "based on the same authorization grant."
|
|
|
|
> [§3] "The access tokens may be self-contained so that a resource server needs no further interaction with an authorization server issuing these tokens" [...] "to perform an authorization decision of the client requesting access to a protected resource."
|
|
|
|
> [§3] "Another design alternative is to issue short-lived access tokens, which can be refreshed at any time using the corresponding refresh tokens."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| RFC7009-C1 | Token revocation endpoint 의 목적은 client 가 authorization server 에게 특정 token 을 무효화해달라고 HTTP POST 로 요청하는 것 | [§2] "The client requests the revocation of a particular token by making an HTTP POST request to the token revocation endpoint URL." | official-standard | 모든 RFC 7009 준수 revocation endpoint 의 일반 목적 정의(Keycloak `/protocol/openid-connect/revoke` 포함, 단 준수 여부는 벤더 문서로 별도 확인) | Keycloak 의 특정 엔드포인트가 실제로 이 RFC 를 완전히 준수하는지 자체는 증명하지 않음 |
|
|
| RFC7009-C2 | `token` 파라미터는 REQUIRED — 무효화할 토큰 문자열 | [§2.1] "token REQUIRED. The token that the client wants to get revoked." | official-standard | revocation 요청 구성 시 필수 파라미터 존재 근거 | Keycloak 이 `token` 누락 시 정확히 어떤 에러(HTTP status/body)를 반환하는지는 증명하지 않음 |
|
|
| RFC7009-C3 | `token_type_hint` 는 OPTIONAL — 서버의 token lookup 최적화를 돕는 힌트이며, 명세상 `access_token`/`refresh_token` 두 값이 정의됨 | [§2.1] "token_type_hint OPTIONAL. A hint about the type of the token submitted for revocation. Clients MAY pass this parameter in order to help the authorization server to optimize the token lookup." | official-standard | `token_type_hint=refresh_token` 같은 파라미터 사용의 표준 근거 | 힌트를 생략했을 때 특정 서버(Keycloak)의 실제 조회 성능 차이는 증명하지 않음 |
|
|
| RFC7009-C4 | Refresh token 이 revoke 되고 authorization server 가 access token revocation 을 지원하면, server 는 동일 authorization grant 기반의 모든 access token 도 SHOULD 무효화해야 함(MUST 아닌 SHOULD — 지원 여부에 달림) | [§2.1] "If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens" [...] "based on the same authorization grant." | official-standard | branch D4 의 "refresh token revoke" 결정이 표준 차원에서 SHOULD 권고로 존재한다는 근거 | Keycloak 이 실제로 이 SHOULD 를 구현했는지, 구현했다면 무효화가 동기적/즉시적인지는 증명하지 않음 — 이는 branch 의 "함정 시연" TODO 가 실측해야 할 gap |
|
|
| RFC7009-C5 | Access token 은 self-contained 하게 발급될 수 있어 resource server 가 authorization server 와 추가 상호작용 없이 인가 판단을 내릴 수 있다 — 이 아키텍처에서는 AS 의 revoke 가 resource server 의 stateless 검증에 즉시 반영되지 않을 수 있음 | [§3] "The access tokens may be self-contained so that a resource server needs no further interaction with an authorization server issuing these tokens" [...] "to perform an authorization decision of the client requesting access to a protected resource." | official-standard | branch 의 "stateless JWT trap" 핵심 표준 근거 — Spring Resource Server 가 JWT 서명/`iss`/`aud`/`exp` 만 검증하고 매 요청 introspection 을 하지 않는 구성이 바로 이 self-contained 아키텍처 | Keycloak 이 기본적으로 self-contained JWT access token 을 발급하는지 자체는 증명하지 않음(Keycloak 벤더 문서로 별도 확인 필요) — RFC 는 일반 아키텍처 설명만 제공 |
|
|
| RFC7009-C6 | Self-contained access token 의 revoke 지연 문제에 대한 설계 대안으로 "짧은 수명의 access token 을 발급하고 refresh token 으로 자주 갱신" 이 제시됨 | [§3] "Another design alternative is to issue short-lived access tokens, which can be refreshed at any time using the corresponding refresh tokens." | official-standard | branch D2(Access Token Lifespan 을 짧게 설정)의 일반적 mitigation 방향성 근거 | "5분" 또는 "5~15분" 이라는 구체적 수치를 권고하지 않음 — 숫자 자체는 각 branch 의 독자적 trade-off 결정으로 남으며, 두 branch-note 의 D2 는 이 claim 만으로 `UNSUPPORTED_DECISION` 라벨을 해제할 수 없음(방향성만 정당화, 수치는 미정당화) |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- 이 자료가 직접 증명하는 것:
|
|
- `RFC7009-C1`~`C3`: revocation endpoint 의 목적과 요청 파라미터 계약(표준 차원)
|
|
- `RFC7009-C4`: refresh token revoke 시 관련 access token 도 SHOULD 무효화된다는 표준 권고
|
|
- `RFC7009-C5`: self-contained access token 아키텍처에서는 revoke 가 resource server 의 stateless 검증에 즉시 반영 안 될 수 있다는 구조적 설명 (branch 의 stateless JWT trap 원인)
|
|
- `RFC7009-C6`: 짧은 access token TTL 이 그 gap 을 줄이는 설계 대안이라는 일반 원칙
|
|
- 이 자료가 증명하지 않는 것:
|
|
- Keycloak 이 RFC 7009 를 완전히 준수하는지 자체 (Keycloak Server Admin Guide 등 벤더 문서 별도 필요)
|
|
- Refresh Token Rotation 의 "reuse detection → family invalidate" 메커니즘 — RFC 7009 는 rotation 자체를 규정하지 않음(rotation 권고는 OAuth 2.1 draft 영역, [[raw/official-docs/oauth-v2-1-draft-ietf]] 참조)
|
|
- 구체적 TTL 수치("5분", "5~15분") 권장값 — RFC 는 방향성(short-lived)만 제시
|
|
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
|
|
- 실제 Keycloak `/realms/<realm>/protocol/openid-connect/revoke` 응답이 `token_type_hint` 별로 §2.1/§2.2 계약과 일치하는지 curl 로 직접 검증 (두 branch 의 `planned`/`needs-confirmation` TODO)
|
|
- revoke 후 access token 이 만료 전까지 실제로 200 을 반환하는지 (branch 의 "함정 시연" 실측)
|
|
|
|
## 메모 / Notes
|
|
|
|
- RFC 7009 는 explicit revoke request/response 계약과 self-contained token 의 구조적 한계만 다룬다. Rotation(reuse detection/family invalidate)은 이 RFC 의 범위가 아니라 OAuth 2.1 draft 의 권고 영역이므로, 두 branch 는 "RFC 7009 ≠ rotation spec" 구분을 유지해야 함.
|
|
- 본 note 는 WebFetch 를 3회 나눠 호출해 얻은 결과를 결합했다(1차: 요약 패스, 2차: §2/§2.1/§2.2/Security Considerations 타깃 발췌, 3차: §2.1 cascading 문장 + §3 Implementation Note 타깃 발췌). 원문의 Security/Privacy Considerations 절대 번호(§4 vs §5)는 fetch pass 간 표기가 엇갈려 본 note 에서는 확신 가능한 §2, §2.1, §3 인용만 Claims 근거로 사용했다.
|
|
- 추가로 봐야 할 동일 출처 페이지: RFC 7009 §4 Security Considerations 전문(현재 절 번호 불확실 — 재확인 필요), §7 IANA Considerations (token_type_hint 값 registry).
|
|
|
|
## Related / 관련
|
|
|
|
- [[raw/official-docs/oauth-v2-1-draft-ietf]] — refresh token rotation 권고(OAuth 2.1 draft, 본 RFC 는 rotation 자체를 규정하지 않음)
|
|
- [[raw/official-docs/keycloak-securing-apps-overview-official]] — Keycloak 토큰 관리/logout 흐름 공식 문서(protocol overview 수준, revoke 세부 미포함)
|
|
- [[raw/official-docs/oauth2-pkce-rfc-7636]] — PKCE(refresh token 보안 맥락)
|