donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
6c53ded9cb70f2d7cf3e66ff50d42f2d151c98b1
llm-wiki/vault/20-evidence/official-docs/oauth-v2-1-draft-ietf.md
T

9.2 KiB
Raw Blame History

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
keycloak-patterns
p2a-spa-resource-server
oauth2
oauth2.1
pkce
bff
ietf-draft
official-standard
keycloak-patterns
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
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

핵심 인용 / 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 / 관련

Reference in New Issue View Git Blame Copy Permalink