9.2 KiB
9.2 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OAuth 2.1 Authorization Framework — IETF draft | official-doc | https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ | raw | high |
|
|
|
2026-05-25 | 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 MUSTOA21-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
- Keycloak 26.x 의 PKCE S256 enforce 설정 (
메모 / 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:
- 인용하는 branch:
- 인용하는 wiki: (미작성)