11 KiB
11 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| official-doc / RFC 7009 — OAuth 2.0 Token Revocation | official-doc | https://datatracker.ietf.org/doc/html/rfc7009 |
|
|
|
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-confirmationTODO) - revoke 후 access token 이 만료 전까지 실제로 200 을 반환하는지 (branch 의 "함정 시연" 실측)
- 실제 Keycloak
메모 / 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 보안 맥락)