브라우저에서 타사 쿠키 차단을 처리하는 방법

  • 아티클

대다수의 브라우저는 브라우저의 주소 표시줄에 표시된 도메인이 아닌 다른 도메인에 대한 요청에 대한 쿠키인 타사 쿠키를 차단합니다. 이러한 쿠키는 도메인 간 쿠키라고도 합니다. 이렇게 차단하면 암시적 흐름이 중단되며, 사용자 로그인에 성공하려면 새 인증 패턴이 필요합니다. Microsoft ID 플랫폼에서는 PKCE(Proof Key for Code Exchange) 및 새로 고침 토큰과 함께 권한 부여 흐름을 사용하여 타사 쿠키가 차단될 때 사용자 로그인 상태를 유지합니다.

ITP(Intelligent Tracking Protection) 및 개인 정보 샌드박스란?

Apple Safari에는 Intelligent Tracking Protection또는 ITP라는 개인 정보 보호 기능이 기본적으로 설정되어 있습니다. Chrome에는 개인 정보 샌드박스라는 브라우저 개인 정보 보호 이니셔티브가 있습니다. 이러한 이니셔티브는 브라우저의 다양한 브라우저 개인 정보 보호 노력을 포함하며 타임라인 다릅니다. 두 작업 모두 교차하는 요청에 대해 "타사" 쿠키를 차단하고기본 Safari와 Brave는 기본적으로 타사 쿠키를 차단합니다. Chrome은 최근 기본적으로 타사 쿠키를 차단하기 시작한다고 발표했습니다. 개인 정보 샌드박스에는 분할된 스토리지에 대한 변경 내용과 타사 쿠키 차단이 포함됩니다.

일반적인 형태의 사용자 추적은 백그라운드에서 타사 사이트에 iframe을 로드하고 쿠키를 사용하여 인터넷을 통해 사용자를 상호 연결함으로써 실행됩니다. 아쉽게도 이 패턴은 단일 페이지 앱(SPA)에서 암시적 흐름을 구현하는 표준 방법이기도 합니다. 사용자 개인 정보를 보호하기 위해 타사 쿠키를 차단하는 브라우저는 SPA의 기능을 차단할 수도 있습니다.

이 문서에서 간략히 설명한 솔루션은 이러한 모든 브라우저에서 작동하며 또는 타사 쿠키가 차단되는 모든 브라우저에서 작동합니다.

솔루션 개요

SPA에서 사용자 인증을 계속 진행하려면 앱 개발자가 권한 부여 코드 흐름을 사용해야 합니다. 인증 코드 흐름에서 ID 공급자는 코드를 발급하고 SPA는 액세스 토큰 및 새로 고침 토큰에 대한 코드를 사용합니다. 앱에 새 토큰이 필요한 경우 새 토큰 흐름을 사용하여 새 토큰을 가져올 수 있습니다. JavaScript v2.0 이상용 MSAL(Microsoft 인증 라이브러리)은 SPA에 대한 인증 코드 흐름을 구현하고, 사소한 업데이트를 통해 MSAL.js 1.x를 즉시 대체합니다. 암시적 코드 흐름에서 인증 코드 흐름으로 SPA를 이동하려면 마이그레이션 가이드를 참조하세요.

Microsoft ID 플랫폼의 경우, SPA 및 네이티브 클라이언트는 다음과 같이 비슷한 프로토콜 지침을 따릅니다.

  • PKCE 코드 챌린지의 사용
    • PKCE는 Microsoft ID 플랫폼에서 SPA에 필요합니다. PKCE는 네이티브 및 기밀 클라이언트에 권장됩니다.
  • 클라이언트 암호 사용 안 함

SPA에는 두 가지 제한 사항이 더 있습니다.

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

성능 및 UX 영향

암시적 흐름을 사용하는 일부 애플리케이션은 prompt=none을 사용해 로그인 iframe을 열어 리디렉션하지 않고 로그인을 시도합니다. 대부분의 브라우저에서 이 요청은 현재 로그인한 사용자에 대한 토큰으로 응답합니다(동의가 부여된 것으로 가정). 이 패턴은 애플리케이션에서 사용자가 로그인하기 위해 전체 페이지 리디렉션을 할 필요가 없으며, 성능 및 사용자 환경이 향상됨을 의미합니다(사용자가 웹 페이지를 방문하여 이미 로그인한 상태). 타사 쿠키가 차단되면 iframe의 prompt=none은(는) 더 이상 옵션이 아니기 때문에 애플리케이션은 인증 코드가 발급되도록 로그인 패턴을 조정해야 합니다.

타사 쿠키 없이 로그인을 수행하는 두 가지 방법이 있습니다.

  • 전체 페이지 리디렉션
    • SPA를 맨 처음 로드할 때 세션이 없거나 만료된 경우 사용자를 로그인 페이지로 리디렉션합니다. 사용자의 브라우저는 로그인 페이지를 방문하여 사용자 세션이 포함된 쿠키를 표시한 다음 조각의 코드 및 토큰을 사용하여 애플리케이션으로 다시 리디렉션됩니다.
    • 이 리디렉션이 발생하면 SPA가 두 번 로드됩니다. 앱이 완전히 두 번 다운로드되지 않도록 SPA 캐싱에 대한 모범 사례를 따릅니다.
    • 앱이 완전히 압축을 풀고 JavaScript 페이로드를 실행하기 전에 로그인 세션을 확인하고 로그인 페이지로 리디렉션하는 미리 로드 시퀀스를 앱에 포함시키는 것이 좋습니다.
  • 팝업
    • 전체 페이지 리디렉션의 UX(사용자 환경)가 애플리케이션에 대해 작동하지 않는 경우, 팝업을 사용하여 인증을 처리하는 것이 좋습니다.
    • 인증 후 팝업이 애플리케이션에 대한 리디렉션을 완료하면 리디렉션 처리기의 코드는 사용할 애플리케이션에 대한 인증 코드와 토큰을 로컬 스토리지에 저장합니다. MSAL.js는 대부분의 라이브러리와 마찬가지로 인증을 위한 팝업을 지원합니다.
    • 브라우저는 팝업에 대한 지원을 줄이고 있기 때문에 가장 안정적인 옵션이 아닐 수도 있습니다. 브라우저 요구 사항을 충족하려면 팝업을 만들기 전에 SPA와 사용자 상호 작용이 필요할 수 있습니다.

Apple은 타사 쿠키에 대한 액세스 권한을 원래의 창에 제공하는 임시 호환성 수정으로서 팝업 방법을 설명합니다. Apple은 나중에 이러한 권한 이전을 제거할 수 있지만 본 지침에는 영향을 미치지 않습니다.

여기서는 세션이 검색되고 인증 코드를 제공할 수 있도록 로그인 페이지에 대한 첫 번째 파티 탐색으로 팝업이 사용됩니다. 이러한 작업은 앞으로도 계속 진행되어야 합니다.

개발자는 타사 쿠키가 차단될 때 interacion_required 오류 발생률이 더 높아질 것이라는 기대를 가지고 prompt=none을(를) 계속 사용할 수 있습니다. 자동 토큰 획득 중에 오류가 발생하는 경우 항상 대화형 메서드 대체를 사용하는 것이 좋습니다.

iframe 사용

웹앱의 일반적인 패턴은 iframe을 사용하여 한 앱을 다른 앱 내에 포함하는 것입니다. 최상위 프레임은 사용자 인증을 처리하고 iframe에 호스트된 애플리케이션은 사용자가 로그인되어 암시적 흐름을 사용하여 토큰을 자동으로 페치하는 것을 신뢰할 수 있습니다. 그러나 브라우저에서 타사 쿠키가 사용하도록 설정되거나 차단되는지 여부에 관계없이 이 가정에는 몇 가지 주의 사항이 있습니다.

타사 쿠키가 차단되면 자동 토큰 획득이 더 이상 작동하지 않습니다. iframe에 포함된 애플리케이션은 포함된 프레임 내에서 로그인 페이지로 이동할 수 없으므로 팝업을 사용하여 사용자 세션에 액세스하도록 전환해야 합니다.

부모 앱에서 iframe 앱으로 사용자(계정) 힌트를 전달하여 동일한 원본 및 원본 간 JavaScript 스크립트 API 액세스 권한이 있는 iframe 앱과 부모 앱 간에 Single Sign-On을 구현할 수 있습니다. 자세한 내용은 GitHub의 MSAL.js 리포지토리에서 iframe 앱에서 MSAL.js 사용을 참조하세요.

브라우저에서 새로 고침 토큰의 보안 관련 사항

사이트 간 스크립팅(XSS) 공격 또는 손상된 JS 패키지는 새로 고침 토큰을 도용할 수 있으며 만료되거나 해지될 때까지 이 토큰을 원격으로 사용할 수 있습니다. 애플리케이션 개발자는 사이트 간 스크립팅에 대한 애플리케이션의 위험을 줄일 책임이 있습니다. 새로 고침 토큰 도난 위험을 최소화하기 위해 SPA는 24시간 동안만 유효한 토큰을 발급합니다. 24시간 후 앱은 로그인 페이지에 대한 최상위 프레임 방문을 통해 새 인증 코드를 획득해야 합니다.

수명이 제한된 이 새로 고침 토큰 패턴은 보안과 성능이 저하된 UX 간의 균형으로 선택되었습니다. 새로 고침 토큰 또는 타사 쿠키가 없다면 새 토큰 또는 추가 토큰이 필요할 때 (OAuth 보안 모범 사례 초안에서 권장하는) 인증 코드 흐름은 번거로워집니다. 토큰이 만료될 때마다(Microsoft ID 플랫폼 토큰의 경우에는 대체로 1시간마다) 모든 단일 토큰에 대해 전체 페이지 리디렉션 또는 팝업이 필요합니다.

사용자 유형별 완화

모든 사용자와 애플리케이션이 타사 쿠키의 영향을 균일하게 받는 것은 아닙니다. 아키텍처 또는 디바이스 관리로 인해 타사 쿠키 없이 토큰 갱신에 대한 자동 호출을 수행할 수 있는 몇 가지 시나리오가 있습니다.

관리되는 엔터프라이즈 디바이스 시나리오의 경우 특정 브라우저 및 플랫폼 조합은 디바이스 조건부 액세스를 지원합니다. 디바이스 ID를 적용하면 브라우저 대신 디바이스에서 인증 상태를 가져올 수 있으므로 타사 쿠키의 필요성이 최소화됩니다.

Azure AD B2C 애플리케이션 시나리오의 경우 고객은 애플리케이션의 도메인과 일치하도록 사용자 지정 로그인 도메인을 설정할 수 있습니다. 쿠키가 동일한 도메인(예: app.contoso.com login.contoso.com)에 남아 있으므로 이 시나리오에서 브라우저는 타사 쿠키를 차단하지 않습니다.

타사 쿠키가 없는 프런트 채널 로그아웃에 대한 제한 사항

SPA에서 사용자를 로그아웃할 때 MSAL.js는 팝업 또는 리디렉션 로그아웃 메서드를 사용하는 것이 좋습니다. 이렇게 하면 서버와 브라우저 스토리지의 인증 세션이 지워지지만 타사 쿠키에 액세스하지 않으면 페더레이션된 모든 애플리케이션에서 동시에 로그아웃이 표시되지 않을 위험이 있습니다. 이는 OpenID 프런트 채널 로그아웃 1.0 사양의 알려진 제한 사항입니다. 사용자에게 의미하는 바는 동일한 사용자의 다른 애플리케이션에 대한 기존 액세스 토큰이 만료 시간까지 계속 유효하다는 것입니다. 사용자는 탭 A에서 애플리케이션 A에서 로그아웃할 수 있지만, 탭 B의 애플리케이션 B는 여전히 유효한 시간을 기본 액세스 토큰의 로그인으로 표시됩니다. 애플리케이션 B의 토큰이 만료되고 새 토큰을 가져오기 위해 서버에 대한 호출이 수행되면 애플리케이션 B는 서버로부터 세션이 만료되었다는 응답을 받고 사용자가 인증하라는 메시지를 표시합니다.

Microsoft의 로그아웃 페이지 및 인터넷 개인 정보 보호 모범 사례는 사용자가 애플리케이션에서 로그아웃한 후 모든 브라우저 창을 닫을 것을 권장합니다.

다음 단계

권한 부여 코드 흐름 및 MSAL.js에 대한 자세한 내용은 다음을 참조하세요.