llm-wiki/raw/official-docs/third-party-cookie-blocking-safari-webkit-official.md at docs/ca-skeleton-frontend-runtime-adapter-features

donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.8 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

source_type 근거

official-doc 로 분류: WebKit Blog 는 Apple 의 브라우저 엔진(WebKit)을 만드는 팀이 자신들이 실제로 출시한(shipped) 정책 변경을 발표하는 공식 채널이다. 일반적인 "회사 기술 블로그(사례 공유)"가 아니라 벤더 자신의 제품 동작을 규정하는 1차 출처이므로 사용자 지정대로 official-doc (vendor-doc) 취급.

Parent / 활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-spa-token-storage-tradeoff	D3 — Safari 의 Intelligent Tracking Prevention (ITP) 가 기본적으로 third-party cookie 를 차단하므로, Keycloak 이 SPA 와 cross-site 로 서빙될 때 hidden-iframe silent renew(`prompt=none`, Keycloak SSO 세션 cookie 의존)가 실패한다는 결정의 근거

출처 / Source

원본 URL: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
아카이브 URL: (미제공)
저자 / 조직: John Wilander (WebKit / Apple, Safari ITP 팀)
발행일: 2020-03-24 (Mar 24, 2020)
마지막 확인일: 2026-07-18

왜 저장했는지 / Why archived

Keycloak 을 SPA 와 다른 registrable domain(cross-site)에 서빙할 경우 hidden-iframe + prompt=none silent renew 가 Safari 에서 실패하는 이유를 벤더 1차 출처로 뒷받침하기 위해 저장. feature-keycloak-spa-token-storage-tradeoff branch 의 D3 (UNSUPPORTED_DECISION 상태였던 silent renew 3rd-party cookie 제약 결정)를 보강한다.

핵심 인용 / Key quotes (verbatim, 4문장)

[byline] "Full Third-Party Cookie Blocking and More / Mar 24, 2020 / by John Wilander"

[본문] "This blog post covers several enhancements to Intelligent Tracking Prevention (ITP) in iOS and iPadOS 13.4 and Safari 13.1 on macOS"

[본문] "Cookies for cross-site resources are now blocked by default across the board. This is a significant improvement for privacy since it removes any sense of exceptions or 'a little bit of cross-site tracking is allowed.'"

[본문] "To keep supporting cross-site integration, we shipped the Storage Access API two years ago to provide the means for authenticated embeds to get cookie access with mandatory user control."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
WEBKIT-3PC-C1	Safari(WebKit)는 이 릴리스부터 cross-site 리소스의 cookie 를 예외 없이 기본 차단한다	"Cookies for cross-site resources are now blocked by default across the board."	`official-vendor-doc`	Safari 13.1(macOS) 이상, iOS/iPadOS 13.4 이상의 모든 cross-site(third-party) cookie 요청	"cross-site" 를 가르는 정확한 경계(registrable domain / eTLD+1 기준)는 본 포스트에 명시되지 않음 — 별도 ITP 분류 기준 문서로 보강 필요. 이후 버전에서 정책이 완화/강화됐는지도 본 포스트만으로는 알 수 없음
WEBKIT-3PC-C2	이번 변경은 기존에 존재하던 "일부 cross-site tracking 은 허용"이라는 예외 모델을 완전히 제거한 것이라는 privacy 개선으로 프레이밍된다	"This is a significant improvement for privacy since it removes any sense of exceptions or 'a little bit of cross-site tracking is allowed.'"	`official-vendor-doc`	WEBKIT-3PC-C1 이 "부분 허용" 이 아니라 "완전 차단"임을 재확인하는 보조 근거	이 문장 자체가 어떤 구체적 예외(Storage Access API 등)가 여전히 존재하는지는 설명하지 않음 — 그 예외는 C3 별도
WEBKIT-3PC-C3	Cross-site 통합(예: 인증된 임베드)을 계속 지원하기 위해 WebKit 은 Storage Access API 를 제공하며, 이 API 는 사용자의 명시적 동의(mandatory user control) 를 전제로 cookie 접근 권한을 부여한다	"To keep supporting cross-site integration, we shipped the Storage Access API two years ago to provide the means for authenticated embeds to get cookie access with mandatory user control."	`official-vendor-doc`	인증된 iframe/임베드가 cookie 접근이 필요할 때의 벤더 제공 우회 경로 존재 여부	Keycloak 의 hidden-iframe `prompt=none` silent renew 흐름이 실제로 Storage Access API 를 호출/통과할 수 있는지는 이 인용만으로 증명되지 않음 — Storage Access API 는 일반적으로 사용자 제스처(예: 클릭)를 요구하는 것으로 알려져 있어, 배경에서 자동 실행되는 `prompt=none` iframe 흐름과는 상충 가능성이 있다. 이 상충 여부는 별도 확인 필요 (`needs-confirmation`)
WEBKIT-3PC-C4	본 정책은 iOS/iPadOS 13.4 및 macOS Safari 13.1 에서 2020년 3월 24일자로 출시(shipped)되었다	"This blog post covers several enhancements to Intelligent Tracking Prevention (ITP) in iOS and iPadOS 13.4 and Safari 13.1 on macOS" + byline "Mar 24, 2020"	`official-vendor-doc`	정책 발효 시점의 하한선(baseline) 확정 — 이 날짜 이후 출시된 Safari 는 기본적으로 이 정책을 포함	실제 사용자 단말의 OS 업데이트 반영 시점(디바이스별 상이)은 증명하지 않음. 이후 Safari 버전에서 정책이 그대로 유지되는지도 이 포스트만으로는 보장 안 됨(ITP 는 계속 진화)

Strength 허용값 참고

official-vendor-doc 채택 — WebKit(Apple)이 자사 브라우저 엔진의 출시된 동작을 발표하는 벤더 공식 채널이므로 company-case-study 가 아님. RFC/표준 사양은 아니므로 official-standard 는 아님.

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- WEBKIT-3PC-C1, WEBKIT-3PC-C4: Safari 13.1(macOS) / iOS·iPadOS 13.4 (2020-03-24) 이후, cross-site cookie 는 예외 없이 기본 차단된다.
- WEBKIT-3PC-C3: WebKit 은 이 차단에 대한 벤더 공식 우회 경로(Storage Access API, 사용자 동의 필요)를 제공한다.
이 자료가 증명하지 않는 것:
- "same-site vs cross-site" 를 가르는 기술적 경계(registrable domain / eTLD+1 등)의 정의 — 본 포스트에는 해당 정의가 없음. 이 경계 기준이 필요하면 별도 WebKit ITP 문서로 보강해야 함.
- Keycloak 의 hidden-iframe prompt=none silent renew 가 Storage Access API 의 사용자 제스처 요구 조건과 충돌하는지 여부(추론이지 이 자료의 직접 진술 아님).
- Chrome 등 비-WebKit 브라우저의 third-party cookie 정책(별도 자료 필요, 예: Chrome Privacy Sandbox 공지).
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 실제 배포 토폴로지에서 Keycloak 호스트와 SPA 호스트가 같은 registrable domain(eTLD+1)인지 아닌지 확인 — 같은 registrable domain(same-site)이면 본 정책의 영향을 받지 않아 D3 전제 자체가 성립하지 않을 수 있음.
- feature-keycloak-vanilla-js-spa-pkce 구현 단계에서 Safari 에서 실제로 silent renew 가 실패하는지 e2e 재현 확인.

메모 / Notes

나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것 (그것은 wiki/concepts의 source-summary 또는 wiki/projects 본문에서만 작성).

Chrome 의 third-party cookie phase-out 정책은 별도 vendor 자료(Google/Chrome 공식 발표) 로 확인 필요 — 본 자료는 WebKit(Safari) 한정.
"cross-site" 경계 정의(eTLD+1/registrable domain)는 WebKit 의 다른 ITP 관련 포스트(예: ITP 초기 분류 기준 포스트)에서 찾아야 할 수 있음 — 후속 조사 후보.

같은 주제 다른 official-doc / company-tech-blog: (Chrome third-party cookie phase-out 공식 자료 — 아직 raw 에 없음, 후속 조사 후보)
이 자료를 인용한 wiki 요약: (아직 생성되지 않음)

8.8 KiB Raw Permalink Blame History

WebKit — Full Third-Party Cookie Blocking and More (Safari 13.1 / iOS 13.4)