12 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| official-doc / OAuth 2.0 for Browser-Based Applications (IETF draft-ietf-oauth-browser-based-apps-27) | official-doc | https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps | raw | high |
|
|
2026-07-14 | 2026-07-14 |
OAuth 2.0 for Browser-Based Applications — IETF draft (draft-ietf-oauth-browser-based-apps-27)
Layer:
raw/— 외부 자료(공식 문서)의 원문 발췌·출처 기록. 검증된 요약은/ingest후wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.
source_type 확인
official-doc — IETF Web Authorization Protocol (oauth) Working Group Internet-Draft. Intended RFC status: Best Current Practice. 회사 기술 블로그 아님 — 벤더 편향 없는 표준화 트랙 문서.
Parent / 활용 branch (필수)
이 자료는 특정 sub-branch 가 아니라 keycloak-patterns 프로젝트 전체의 taxonomy 결정에 대한 foundational 근거로 수집됨 — 6개 배치 패턴(P1~P3, Google federation 유무)을 분류하는 축 자체가 이 draft 가 정의하는 "3대 아키텍처 패턴 + 보안 감소 순서" 모델을 준거로 삼는다.
| Parent | 이 자료가 정당화하는 결정 |
|---|---|
| raw/project-notes/keycloak-patterns-overview | 프로젝트의 6-패턴 taxonomy(§2 P1/P2/P3 분류 축)가 업계 표준 3대 아키텍처(BFF / Token-Mediating Backend / Browser-based OAuth Client) 및 그 "decreasing order of security" 순서와 정합함을 보이는 근거. 특히 P1(Edge proxy)·P2(SPA-direct)의 신뢰 경계 설명(§3 공통 컴포넌트, §8 자신 없는 부분 "BFF 패턴 실 구현 경험 부재")이 참조하는 표준 정의의 출처. |
출처 / Source
- 원본 URL: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
- 아카이브 URL: (미제공)
- 저자 / 조직: Aaron Parecki (Okta), Philippe De Ryck (Pragmatic Web Security), David Waite (Ping Identity) — IETF Web Authorization Protocol (oauth) Working Group
- 발행일: 2026-07-06 (draft-ietf-oauth-browser-based-apps-27, Expires 2027-01-07)
- 마지막 확인일: 2026-07-14
왜 저장했는지 / Why archived
keycloak-patterns 프로젝트의 6-패턴 분류(§2)는 "배치 위치 × Google federation" 축으로 나뉘지만, 그 밑바탕에는 "누가 토큰을 들고 있고 누가 resource server 와 직접 통신하는가"라는 업계 표준 3분류(BFF / Token-Mediating Backend / Browser-based Client)가 있다. 이 draft 는 그 3분류를 정의하고 "decreasing order of security" 로 명시적으로 서열화한 IETF 표준 트랙 근거이므로, P1(Edge ForwardAuth)·P2(SPA-direct) 패턴 설명과 §8 "BFF 패턴 실 구현 경험 부재" 갭을 근거 있게 기술하기 위해 보관.
핵심 인용 / Key quotes (verbatim, 5문장)
[§6] "A browser-based application that relies on a backend component for handling OAuth responsibilities and forwards all requests through the backend component (Backend-For-Frontend or BFF)"
[§6] "A browser-based application that relies on a backend component for handling OAuth responsibilities, but calls resource servers directly using the access token (Token-Mediating Backend)"
[§6] "A browser-based application acting as the client, handling all OAuth responsibilities in the browser (Browser-based OAuth Client)"
[§6] "Each of these architectural patterns offers a different trade-off between security and simplicity. The patterns in this section are presented in decreasing order of security."
[§6.2] "The token-mediating backend pattern is more lightweight than the BFF pattern (See Section 6.1), since it does not require the proxying of all requests and responses between the application and the resource server." [...] "the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OAUTH-BBA-C1 | BFF 패턴: backend 컴포넌트가 confidential OAuth client 로서 모든 토큰을 쿠키 세션 컨텍스트에 보관하고, 브라우저에는 토큰을 노출하지 않으며, resource server 로 가는 모든 요청을 backend 가 프록시(forward)한다. | [§6] "...forwards all requests through the backend component (Backend-For-Frontend or BFF)" / [§6.1.1] "The BFF manages OAuth access and refresh tokens in the context of a cookie-based session, avoiding the direct exposure of any tokens to the browser-based application" | official-standard | 일반 browser-based OAuth/OIDC 아키텍처 정의. keycloak-patterns P1(Edge ForwardAuth) 계열의 "프록시가 인증, 백엔드는 인증된 요청만" 신뢰 경계 서술의 표준 출처. | oauth2-proxy/Traefik ForwardAuth(P1A/P1B)가 이 draft 의 BFF 정의와 1:1 동일하다는 것 — BFF 는 "프론트엔드 애플리케이션의 구성요소로서 그 자체가 OAuth client" 인 반면, oauth2-proxy 는 범용 forward-auth 게이트웨이. 매핑 정합성은 별도 확인 필요. |
| OAUTH-BBA-C2 | Token-Mediating Backend 패턴: backend 가 confidential client 로 토큰을 획득하지만, 브라우저 앱에 access token 을 직접 건네주어 앱이 resource server 와 직접 통신하게 한다(요청 프록시 없음). | [§6] "...but calls resource servers directly using the access token (Token-Mediating Backend)" / [§6.2] "The backend component then provides the application with the access token to directly interact with resource servers." | official-standard | keycloak-patterns 프로젝트의 "누가 토큰을 들고 resource server 와 통신하는가" 축 정의에 대한 표준 참조점. | keycloak-patterns 의 P1~P3 6개 조합 중 어느 것이 정확히 이 패턴에 해당하는지의 1:1 매핑 — 이 draft 는 일반 패턴만 정의, project-specific 매핑은 별도 branch-note 결정. |
| OAUTH-BBA-C3 | Browser-based OAuth 2.0 Client 패턴: 브라우저 앱 자체가 public client(client credentials 없음)로서 모든 OAuth 책임을 브라우저에서 처리하고, resource server 와 직접 통신한다. | [§6.3] "...handling all OAuth responsibilities in the browser. As a result, the browser-based application obtains tokens from the authorization server, without the involvement of a backend component." / [§6.3.1] "In this architecture, the code is first loaded from a static web host into the browser (A), and the application then runs in the browser. In this scenario, the browser-based application is considered a public client, which does not possess client credentials to authenticate to the authorization server." | official-standard | keycloak-patterns P2A/P2B(SPA-direct OIDC, edge proxy 없음)의 아키텍처 설명과 정합. | 이 패턴이 금지되거나 비권장이라는 것 — draft 는 trade-off 만 기술, 배제하지 않음(PKCE 필수 조건 하에 허용). |
| OAUTH-BBA-C4 | 세 패턴은 draft 본문에서 보안 감소 순서(BFF → Token-Mediating Backend → Browser-based Client)로 제시된다. | [§6] "Each of these architectural patterns offers a different trade-off between security and simplicity. The patterns in this section are presented in decreasing order of security." | official-standard | keycloak-patterns branch-note 들의 "보안 vs 단순성" trade-off 서술 프레이밍 근거. | "보안 감소"가 곧 "특정 배치 환경에서 부적합"을 의미한다는 것 — 적합성은 위협 모델에 따라 별도 판단 필요. |
| OAUTH-BBA-C5 | BFF 와 Token-Mediating Backend 의 구분: TMB 는 앱-resource server 간 모든 요청/응답을 프록시할 필요가 없어서 BFF 보다 경량이지만, 그 결과 BFF 보다 보안 수준이 낮다(단 순수 브라우저 client 보다는 안전). | [§6.2] "The token-mediating backend pattern is more lightweight than the BFF pattern (See Section 6.1), since it does not require the proxying of all requests and responses between the application and the resource server." [...] "the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser." | official-standard | keycloak-patterns 프로젝트에서 BFF vs Token-Mediating Backend 를 구분해야 하는 taxonomy 결정의 직접 근거. | 정량적 보안 차이(CVE/attack-surface 측정값) — 이 문장은 정성적 진술. |
Strength 근거
- 모든 claim
official-standard— IETF Web Authorization Protocol WG의 Internet-Draft, Intended RFC status: Best Current Practice. RFC 편집 전 draft 이므로 향후 문구가 바뀔 수 있으나(버전 -27, 2026-07-06), IETF 표준화 트랙 공식 문서로서 벤더 편향 없는 기준으로 사용 가능.
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
OAUTH-BBA-C1~C3: BFF / Token-Mediating Backend / Browser-based OAuth 2.0 Client 세 패턴의 정의(토큰 위치, resource server 통신 주체)OAUTH-BBA-C4: 세 패턴이 "decreasing order of security" 로 제시된다는 문장 그 자체OAUTH-BBA-C5: BFF 와 Token-Mediating Backend 를 가르는 "요청 프록시 여부" + 상대적 보안 순위
- 이 자료가 증명하지 않는 것:
- Keycloak 이 이 세 패턴 중 어느 것을 "공식 권장"한다는 것 (이 draft 는 Keycloak 문서가 아니라 IETF 일반 표준)
- keycloak-patterns 프로젝트의 P1A/P1B/P2A/P2B/P3A/P3B 6개 구체적 조합이 이 3분류와 1:1로 정확히 대응한다는 것 — 특히 P1(oauth2-proxy/Traefik ForwardAuth)이 이 draft 의 "BFF" 정의(프론트엔드의 confidential OAuth client 컴포넌트)와 정확히 같은 개념인지는 별도 확인 필요(oauth2-proxy 는 범용 forward-auth 게이트웨이로 설계되어, 이 draft 가 BFF 에 요구하는 "OAuth client 로서 앱별 토큰 관리 + 요청 augmenting" 책임을 항상 동일한 방식으로 지지는 않을 수 있음)
- 정량적 보안 등급(예: "TMB 는 BFF 대비 몇 % 덜 안전한가") — 모두 정성적 서술
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- keycloak-patterns P1(Edge ForwardAuth) 이 실제로 이 draft 의 BFF 아키텍처 요건(§6.1.3 Security Considerations — confidential client, cookie 보안 MUST 항목들)을 만족하는 구현인지 P1 sub-branch 에서 별도 검증
- P2(SPA-direct) 가 이 draft 의 §6.3.2 (PKCE MUST, CSRF 방어 MUST) 요건을 실제로 만족하는지 P2 sub-branch 에서 별도 검증
메모 / Notes
나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것.
- keycloak-patterns §8 "자신 없는 부분"에 있는 "BFF (Backend-for-Frontend) 패턴 실 구현 경험 부재 — 문서만 봤음" 항목은 본 raw 의
OAUTH-BBA-C1을 근거로 보강 가능 (단,documented-only등급 유지 — 실 구현 전까지 승급 금지). - 이 draft 는 RFC 편집 전 Internet-Draft(버전 -27, 2026-07-06 발행, 2027-01-07 만료)이므로, 향후 버전에서 패턴 이름/문구가 갱신될 수 있음.
last_reviewed90일 초과 시/lintstale 후보 처리 대상. - 추가로 봐야 할 동일 출처 페이지: §6.1.3(BFF Security Considerations, cookie MUST 항목), §6.2.4.3(Token-Mediating Backend 추가 방어), §8(브라우저 토큰 저장 옵션) — P1/P2 sub-branch 세부 구현 시 참조.
Related / 관련
- 같은 주제 다른 official-doc: raw/official-docs/oauth-v2-1-draft-ietf (OAuth 2.1 draft — 동일 keycloak-patterns 프로젝트, BFF 태그 공유), raw/official-docs/oauth2-pkce-rfc-7636, raw/official-docs/security-oauth2-pkce-rfc-8252
- 이 자료를 인용한 wiki 요약: (생성 시
[[wiki/concepts/...]]추가)