llm-wiki/raw/official-docs/oauth-v2-1-draft-ietf.md

---
title: OAuth 2.1 Authorization Framework — IETF draft
source_type: official-doc
url: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
archive_url:
status: raw
confidence: high
tags: [keycloak-patterns, p2a-spa-resource-server, oauth2, oauth2.1, pkce, bff, ietf-draft, official-standard]
related_projects: [keycloak-patterns]
related_branches: [feature-keycloak-patterns, feature-keycloak-internal-spa-direct-no-google, feature-keycloak-vanilla-js-spa-pkce, feature-keycloak-pkce-flow-stages, feature-keycloak-bff-vs-spa-direct, feature-keycloak-google-redirect-uri-policy, feature-keycloak-refresh-token-rotation, feature-keycloak-spa-token-storage-tradeoff]
created: 2026-05-25
last_reviewed: 2026-05-27
---

# OAuth 2.1 Authorization Framework (IETF draft)

> Layer: `raw/official-docs/` — IETF OAuth Working Group draft (`draft-ietf-oauth-v2-1`). OAuth 2.0 (RFC 6749) + Security BCP (RFC 9700) 통합 차세대 baseline. P2A 의 PKCE 의무 + BFF 권고의 1차 표준 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-keycloak-patterns]] | keycloak-patterns root — 모든 SPA/BFF 패턴이 OAuth 2.1 표준 권고와 정합하는지 cross-check 의 기준 |
| [[raw/branch-notes/feature-keycloak-internal-spa-direct-no-google]] | P2A SPA Direct — "Authorization Code + PKCE" 가 모든 client 의 primary flow 라는 표준 근거 |
| [[raw/branch-notes/feature-keycloak-vanilla-js-spa-pkce]] | vanilla JS SPA 의 PKCE 강제 (S256) 설계 근거 — `code_challenge`/`code_verifier` MUST |
| [[raw/branch-notes/feature-keycloak-pkce-flow-stages]] | PKCE flow 4단계 (verifier 생성 → challenge 전송 → code 수령 → verifier 제출) 의 표준 의무화 단계 |
| [[raw/branch-notes/feature-keycloak-bff-vs-spa-direct]] | "browser client 가 credentials 를 다루려면 BFF" 권고 — SPA Direct vs BFF 선택의 표준 권고 근거 |
| [[raw/branch-notes/feature-keycloak-google-redirect-uri-policy]] | redirect URI exact-match MUST → wildcard 금지 정책 표준 근거 |
| [[raw/branch-notes/feature-keycloak-refresh-token-rotation]] | refresh token = scope/resource server bound 의무 → rotation + audience binding 결정 근거 |
| [[raw/branch-notes/feature-keycloak-spa-token-storage-tradeoff]] | "browser 에 토큰 저장은 protocol data and credentials are easily accessible" → BFF 권고 배경 |

## 컨텍스트 / 왜 저장했는지

P2A 패턴은 "SPA → Keycloak (Authorization Code + PKCE) → Resource Server (JWT)"의 흐름. OAuth 2.1이 이 흐름을 어떻게 **표준 권고**로 격상시켰는지(PKCE 의무화, implicit 제거, BFF 권고)를 근거로 사용. "왜 P2A를 OWASP 권고 패턴이라 부르는가"의 1차 출처.

## 출처 / Source

- 원본 URL: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
- 아카이브 URL: (미수집)
- 저자 / 조직: IETF OAuth Working Group
- 발행일: rolling draft (확인 시점: 2026-05-27)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§4.1.1] "Clients MUST use code_challenge and code_verifier and authorization servers MUST enforce their use except under the conditions described in Section 7.5.1."

> [§10.1 title] "Removal of the OAuth 2.0 Implicit grant"

> [§1.8] "Furthermore, some features available in OAuth 2.0, such as the Implicit or Resource Owner Credentials grant types, are not specified in OAuth 2.1."

> [§3.2.3] "If refresh tokens are issued, those refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner."

> [§2.1] "If such applications wish to use client credentials, it is recommended to utilize the backend for frontend pattern."

> [§2.3.1] "Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered."

> [§4.1] "The authorization code grant type is used to obtain both access tokens and refresh tokens."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OA21-C1 | OAuth 2.1 에서 모든 client 는 `code_challenge`/`code_verifier` 를 MUST 사용하고, authorization server 는 §7.5.1 예외 외에는 강제 MUST | [§4.1.1] "Clients MUST use code_challenge and code_verifier and authorization servers MUST enforce their use except under the conditions described in Section 7.5.1." | `official-standard` | OAuth 2.1 준수 환경의 모든 authorization code flow | §7.5.1 예외의 정확한 조건 (e.g., confidential client + 인증된 backchannel) 은 본 인용에 명시 없음 |
| OA21-C2 | OAuth 2.0 Implicit grant 와 Resource Owner Password Credentials grant 는 OAuth 2.1 에 명시되지 않음 (제거됨) | [§10.1 title] "Removal of the OAuth 2.0 Implicit grant" + [§1.8] "some features available in OAuth 2.0, such as the Implicit or Resource Owner Credentials grant types, are not specified in OAuth 2.1." | `official-standard` | OAuth 2.1 호환 client 설계 | 기존 OAuth 2.0 deployment 에서 즉시 제거해야 한다는 운영 권고는 본 인용 범위 밖 |
| OA21-C3 | refresh token 이 발급되는 경우 resource owner 가 consent 한 scope 와 resource server 에 bound 되어야 한다 (MUST) | [§3.2.3] "If refresh tokens are issued, those refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner." | `official-standard` | refresh token 발급/검증 정책 | refresh token rotation 의 빈도/만료 정책의 정확한 수치는 본 인용 범위 밖 |
| OA21-C4 | 브라우저 기반 application 이 client credentials 를 사용하려면 backend-for-frontend (BFF) 패턴 권고 | [§2.1] "If such applications wish to use client credentials, it is recommended to utilize the backend for frontend pattern." | `official-standard` | SPA + confidential client 시나리오 | 모든 SPA 가 BFF 를 의무화해야 한다는 뜻은 아님 — public client + PKCE 도 표준 허용 |
| OA21-C5 | authorization server 는 registered redirect URI 와 정확히 (exact) 일치하지 않는 요청을 MUST 거부 | [§2.3.1] "Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered." | `official-standard` | redirect URI 등록 + 매칭 정책 | wildcard / path-prefix 매칭이 모든 시나리오에서 금지된다는 뜻은 본 인용에 명시되지 않음 (다만 "exactly match" 가 표준 요구) |
| OA21-C6 | authorization code grant type 은 access token + refresh token 을 모두 획득하는 데 사용된다 | [§4.1] "The authorization code grant type is used to obtain both access tokens and refresh tokens." | `official-standard` | code flow + refresh token 발급 | 모든 deployment 에서 refresh token 이 자동으로 발급된다는 뜻은 아님 — `offline_access` scope 등 별도 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `OA21-C1`: PKCE 의무화 (`MUST`) — public + confidential 모두
  - `OA21-C2`: Implicit + ROPC grant 제거
  - `OA21-C3`: refresh token = scope + resource server bound 의무
  - `OA21-C4`: SPA + client credentials → BFF 권고
  - `OA21-C5`: redirect URI exact-match MUST
  - `OA21-C6`: code flow 가 access + refresh token 발급의 표준 경로
- **이 자료가 증명하지 않는 것**:
  - Keycloak / Spring Authorization Server 등 특정 구현이 OAuth 2.1 을 완전 준수하는지 (벤더 별 확인 필요)
  - PKCE S256 vs plain 의 선택 — 본 인용에는 method 명시 없음 (별도 RFC 7636)
  - 브라우저 storage (localStorage vs IndexedDB vs cookie) 의 정확한 보안 권고 (별도 OWASP / RFC 9700)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - Keycloak 26.x 의 PKCE S256 enforce 설정 (`Proof Key for Code Exchange Code Challenge Method = S256`)
  - P2A SPA Direct 에서 refresh token 사용 여부 + rotation 활성화
  - redirect URI 등록 시 한 글자 단위로 정확한 SPA callback URL

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. P2A 결정 컨텍스트 해석.

- OAuth 2.0 → 2.1의 주요 변경:
  - PKCE 의무화 (public + confidential 모두).
  - Implicit grant 제거.
  - Resource Owner Password Credentials grant 제거.
  - Redirect URI exact string match.
  - Refresh token rotation 권고 강화.
- P2A 패턴은 OAuth 2.1의 "표준 SPA" 흐름과 일치. 단, 토큰을 브라우저에 두는 것보다 BFF가 더 안전하다는 가이드도 포함 — 본 branch는 학습 목적으로 SPA Direct 채택.
- Keycloak은 PKCE S256을 client 설정 (`Proof Key for Code Exchange Code Challenge Method`)에서 enforce 가능 — OAuth 2.1 권고와 일치.

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/oauth2-pkce-rfc-7636]] (PKCE 의 원형 RFC)
  - [[raw/official-docs/security-oauth2-pkce-rfc-8252]] (Native App BCP)
  - [[raw/official-docs/google-oauth2-redirect-uri-validation-official]]
- 인용하는 branch:
  - [[raw/branch-notes/feature-keycloak-internal-spa-direct-no-google]] (P2A)
  - [[raw/branch-notes/feature-keycloak-bff-vs-spa-direct]]
  - [[raw/branch-notes/feature-keycloak-vanilla-js-spa-pkce]]
- 인용하는 wiki: (미작성)