donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
main
llm-wiki/raw/official-docs/security-oauth2-pkce-rfc-8252.md
T

9.3 KiB
Raw Permalink 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
RFC 8252 — OAuth 2.0 for Native Apps (Authorization Code + PKCE) official-doc https://datatracker.ietf.org/doc/html/rfc8252 raw high
ca-security
oauth2
pkce
authorization-code
native-apps
ietf-rfc
ietf-bcp
ca-skeleton-operational-contract
feature-security-operational-baseline
2026-05-22 2026-05-27

RFC 8252 — OAuth 2.0 for Native Apps

Layer: raw/official-docs/ — IETF RFC 8252 / BCP 212 (Best Current Practice) 발췌. Native app에서 Authorization Code + PKCE를 MUST로 강제하는 표준.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-security-operational-baseline ca-tmpl baseline의 "client flow 가정" 메모 — token issuance가 Authorization Code + PKCE를 전제로 들어온다는 표준 근거

추가로 (foundational 조사 시): raw/project-notes/ca-skeleton-operational-contract — Security Operational Baseline §의 client flow 가정.

컨텍스트

ca-tmpl이 JWT Resource Server를 baseline으로 택한 것은 token 검증 쪽의 결정. 토큰을 발급받는 쪽(즉 client/Frontend)이 어떻게 안전하게 받아오느냐는 별도 결정이며, "왜 implicit flow를 안 쓰는가"·"PKCE는 native가 아니어도 권장되는가"를 답할 근거 자료. ca-tmpl baseline의 대안 후보 중 하나(Authorization Code + PKCE)의 1차 근거.

출처 / Source

  • 원본 URL: https://datatracker.ietf.org/doc/html/rfc8252
  • 아카이브 URL: (미수집)
  • 저자 / 조직: IETF — W. Denniss (Google), J. Bradley (Ping Identity)
  • 발행일: 2017-10 (RFC 8252 / BCP 212)
  • 관련: RFC 7636 (PKCE), RFC 6749 (OAuth 2.0 Framework), RFC 9700 (OAuth 2.0 Security BCP, 2025 후속)
  • 마지막 확인일: 2026-05-27 (WebFetch 재검증 완료 — quote 1, 3 verbatim MATCH; quote 2 는 라이브 문서가 loopback exception 절을 포함, 2026-05-27 update 본 추가)

핵심 인용 / Key quotes (verbatim)

[§6 General App Recommendation, 2026-05-27 verified MATCH] "Public native app clients MUST implement the Proof Key for Code Exchange (PKCE [RFC7636]) extension to OAuth, and authorization servers MUST support PKCE for such clients, for the reasons detailed in Section 8.1."

[§8.10 Registration, 2026-05-22 capture — partial quote, exception 절 누락] "Authorization servers MUST require clients to register their complete redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match the one that was registered."

[§8.4 Registration of Native App Clients (라이브 anchor), 2026-05-27 verified full quote] "Authorization servers MUST require clients to register their complete redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match the one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component."

[§8.2 Implicit Flow, 2026-05-27 verified MATCH] "the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
RFC8252-C1 Public native app client는 PKCE (RFC 7636) 구현이 MUST, authorization server도 해당 client에 대해 PKCE 지원이 MUST [§6, 2026-05-27 verified] "Public native app clients MUST implement the Proof Key for Code Exchange (PKCE [RFC7636]) extension to OAuth, and authorization servers MUST support PKCE for such clients, for the reasons detailed in Section 8.1." official-standard Native app (mobile, desktop) public client SPA (browser-based)에 동일 MUST를 적용한다는 뜻은 아님 — SPA는 RFC 8252 scope 밖, RFC 9700 / OAuth 2.1에서 확장
RFC8252-C2 Authorization server는 client가 완전한 redirect URI (path 포함) 를 등록하도록 강제하고, 등록과 정확히 일치하지 않는 redirect URI 요청은 거부 MUST. 단 loopback redirect 는 port 예외 [§8.4, 2026-05-27 verified full] "Authorization servers MUST require clients to register their complete redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match the one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component." official-standard Native app client의 redirect URI 등록 정책 wildcard / pattern 매칭 정책의 정확한 금지 사유는 본 인용 직접 다루지 않음. loopback port 예외는 본 인용에 포함되어 §7.3 Loopback Interface 가 정의
RFC8252-C3 OAuth 2.0 Implicit grant flow는 PKCE 보호가 불가능하므로 native app에서 사용은 NOT RECOMMENDED [§8.2, 2026-05-27 verified] "the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED." official-standard Native app에서 OAuth flow 선택 Implicit flow의 SPA 사용도 동일하게 NOT RECOMMENDED인가? — RFC 8252는 native app scope, SPA 일반화는 별도 문서 (RFC 9700) 필요

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • RFC8252-C1~C3: Native app public client에 대한 PKCE MUST, redirect URI exact match MUST, Implicit flow NOT RECOMMENDED
  • 이 자료가 증명하지 않는 것:
    • SPA (browser-based) public client에 대한 동일한 MUST — RFC 8252의 scope는 native app
    • Confidential client (server-side)에 대한 PKCE 요구 — RFC 9700 / OAuth 2.1 draft에서 확장
    • 구체적인 redirect URI scheme (custom URI scheme vs claimed HTTPS vs loopback) 권장 우선순위 — §7에서 별도
    • Authorization Code + PKCE가 모든 platform/IDP에서 동일하게 구현 가능하다는 가정 — 각 vendor 지원 여부는 별도 확인
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl이 backend skeleton (Resource Server) 이므로 native app PKCE MUST는 직접 적용 안 됨 — 단지 "들어오는 access token이 PKCE flow를 거쳐 발급됐다고 가정"하는 baseline 전제만 정당화
    • SPA 채택 시 RFC 9700 / OAuth 2.1 draft의 더 강한 PKCE 요구사항 참조 필요
    • Keycloak이 SPA/native client에 PKCE를 client 설정 단위로 강제하는 옵션 위치 확인

ca-tmpl 함의 (내 프로젝트 해석)

본 섹션은 자료 직접 인용이 아닌 baseline 결정 컨텍스트 해석. wiki 추출 시 옮겨야 함.

  • PKCE 적용 범위: RFC 8252는 native app 한정으로 "MUST" 했지만 후속 OAuth 2.0 Security BCP(RFC 9700)는 모든 OAuth client (SPA / web / native 모두) 에 PKCE를 권고. 즉 baseline 후보로서 "Authorization Code + PKCE"는 native에 한정되지 않음.
  • vs JWT Resource Server (ca-tmpl baseline): PKCE는 token issuance flow (client ↔ Authorization Server). JWT Resource Server는 token consumption (client ↔ Resource Server). 둘은 대체재가 아니라 stack의 다른 계층. ca-tmpl이 Resource Server 쪽만 baseline 결정한 것은 정합.
  • 대안 분석 — Authorization Code + PKCE를 ca-tmpl baseline이 직접 다루지 않은 이유:
    • ca-tmpl scope = backend skeleton (Resource Server).
    • Authorization Server 구현 / token 발급 flow는 in-scope가 아님 (branch note "Out of scope: OAuth authorization server 구현"과 일치).
    • 단, client 인증 흐름이 PKCE라고 가정한 상태에서 access token이 들어옴이 baseline의 암묵적 전제.
  • 장점:
    • implicit flow 대비 code interception 공격에 안전 (verifier hash chain).
    • public client(secret 없는 SPA/native)에도 client authentication 효과.
  • 단점 / 한계:
    • Authorization Server 구현 부담 (PKCE 검증 추가).
    • 본 baseline은 Resource Server 결정만이므로 PKCE 채택 여부는 platform/IDP 선택에 종속.

메모 / Notes

  • 2026-05-27 re-verification: WebFetch 재확인 완료. Quote 1, 3 verbatim MATCH (anchor §6, §8.2 confirmed). Quote 2 의 라이브 anchor 는 §8.10 이 아닌 §8.4 — 또한 라이브 본문은 "; the exception is loopback redirects, where an exact match is required except for the port URI component." 절을 추가로 포함. 2026-05-22 capture 는 이 절을 누락한 partial quote 였음 (의미 왜곡은 아니지만 loopback exception 을 명시적으로 보여주지 못함). 2026-05-27 verified 본 quote 를 추가하여 보존.
  • 본 source의 위치: ca-tmpl baseline의 대안 그룹 G-B (Security baseline) 중 대안 3 — Authorization Code + PKCE (issuance flow; ca-tmpl은 consumption만 owns).

Related / 관련

Reference in New Issue View Git Blame Copy Permalink