103 lines
9.3 KiB
Markdown
103 lines
9.3 KiB
Markdown
---
|
|
title: RFC 8252 — OAuth 2.0 for Native Apps (Authorization Code + PKCE)
|
|
source_type: official-doc
|
|
url: https://datatracker.ietf.org/doc/html/rfc8252
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
tags: [ca-security, oauth2, pkce, authorization-code, native-apps, ietf-rfc, ietf-bcp]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-security-operational-baseline]
|
|
created: 2026-05-22
|
|
last_reviewed: 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 / 관련
|
|
|
|
- 같은 주제 다른 official-doc:
|
|
- [[raw/official-docs/oauth2-pkce-rfc-7636]] — PKCE 메커니즘 자체의 표준 정의 (본 RFC가 MUST로 참조)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-security-operational-baseline]]
|
|
- canonical contract 섹션:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (§Security Operational Baseline, "client flow 가정" 메모)
|
|
- 인용한 wiki 요약: (미작성)
|