서드 파티 스토리지 액세스를 차단하는 브라우저에서 signInWithRedirect를 사용하기 위한 권장사항
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 문서에서는 서드 파티 쿠키를 차단하는 브라우저에서 리디렉션 로그인을 사용하기 위한 권장사항을 설명합니다. 모든 브라우저 간에 프로덕션 환경에서 signInWithRedirect()가 의도한 대로 작동하려면 여기에 나온 옵션 중 하나를 따라야 합니다.
개요
Firebase 인증 자바스크립트 SDK는 개발자와 사용자가 원활하게 signInWithRedirect() 흐름을 진행할 수 있도록 앱의 Firebase 호스팅 도메인에 연결되는 교차 출처 iframe을 사용합니다.
그러나 서드 파티 스토리지 액세스를 차단하는 브라우저에서는 이 메커니즘이 작동하지 않습니다.
사용자에게 브라우저에서 스토리지 파티션 나누기 기능을 중지하도록 요청할 수 없으므로 대신 사용 사례의 특성에 따라 다음 설정 옵션 중 하나를 앱에 적용해야 합니다.
firebaseapp.com의 하위 도메인에서 Firebase 호스팅으로 앱을 호스팅하는 경우에는 이 문제의 영향을 받지 않으며 어떠한 작업도 필요 없습니다.
커스텀 도메인이나 web.app의 하위 도메인에서 Firebase 호스팅으로 앱을 호스팅하는 경우 옵션 1을 사용합니다.
옵션 1: 커스텀 도메인을 authDomain으로 사용하도록 Firebase 구성 업데이트
커스텀 도메인을 사용하여 Firebase 호스팅으로 앱을 호스팅하는 경우 Firebase SDK를 구성하여 커스텀 도메인을 authDomain으로 사용할 수 있습니다. 이렇게 하면 앱과 인증 iframe에서 같은 도메인을 사용하므로 로그인 문제가 방지됩니다. Firebase 호스팅을 사용하지 않는 경우에는 다른 옵션을 사용해야 합니다. 인증에 사용하는 것과 동일한 프로젝트에 커스텀 도메인을 설정했는지 확인합니다.
커스텀 도메인을 인증 도메인으로 사용하도록 Firebase 구성을 업데이트하려면 다음을 수행합니다.
OAuth 제공업체의 승인된 리디렉션 URI 목록에 새 authDomain을 추가합니다. 방법은 제공업체에 따라 다르지만 일반적으로 특정 제공업체의 '시작하기 전에' 섹션의 안내에 따라 정확하게 수행할 수 있습니다(예: Facebook 제공업체). 승인하도록 업데이트된 URI는 https://<the-domain-that-serves-your-app>/__/auth/handler와 같으며 여기서 후행 /__/auth/handler가 중요합니다.
마찬가지로 SAML 제공업체를 사용하는 경우 새 authDomain을 SAML 어설션 소비자 서비스(ACS) URL에 추가합니다.
// Before// ==============signInWithRedirect(auth,newGoogleAuthProvider());// After the page redirects backconstuserCred=awaitgetRedirectResult(auth);// After// ==============constuserCred=awaitsignInWithPopup(auth,newGoogleAuthProvider());
Web
// Before// ==============firebase.auth().signInWithRedirect(newfirebase.auth.GoogleAuthProvider());// After the page redirects backvaruserCred=awaitfirebase.auth().getRedirectResult();// After// ==============varuserCred=awaitfirebase.auth().signInWithPopup(newfirebase.auth.GoogleAuthProvider());```
사용자에게 팝업 로그인이 항상 적합한 것은 아닙니다. 기기나 플랫폼에서 팝업을 차단하는 경우가 많으며 모바일 사용자의 경우 흐름이 원활하지 않기 때문입니다. 앱에서 팝업을 사용할 수 없으면 다른 옵션 중 하나를 수행해야 합니다.
옵션 3: firebaseapp.com에 프록시 인증 요청
signInWithRedirect 흐름은 앱 도메인에서 Firebase 구성의 authDomain 매개변수에 지정된 도메인으로 리디렉션됩니다(기본적으로 '.firebaseapp.com'). authDomain은 ID 공급업체로 리디렉션되는 로그인 도우미 코드를 호스팅합니다. 성공하면 이 ID는 앱 도메인으로 다시 리디렉션됩니다.
인증 흐름이 앱 도메인으로 돌아오면 로그인 도우미 도메인의 브라우저 스토리지에 액세스합니다. 이 옵션과 다음 옵션(코드 자체 호스팅)은 교차 출처 스토리지 액세스를 제거합니다. 그렇지 않으면 브라우저에 의해 차단됩니다.
https://<app domain>/__/auth/에 대한 GET/POST 요청이 https://<project>.firebaseapp.com/__/auth/에 전달되도록 앱 서버에 리버스 프록시를 설정합니다.
전달이 브라우저에 표시되는지 확인합니다. 이 전달은 302 리디렉션을 통해 실행될 수 없습니다.
nginx를 사용하여 커스텀 도메인을 제공하는 경우 역방향 프록시 구성은 다음과 같습니다.
# reverse proxy for signin-helpers for popup/redirect sign in.
location/__/auth{proxy_passhttps://<project>.firebaseapp.com;}
옵션 1의 단계에 따라 승인된 redirect_uri, ACS URL, authDomain을 업데이트합니다. 앱을 다시 배포하면 더 이상 교차 출처 스토리지에 액세스할 수 없습니다.
옵션 4: 도메인에서 로그인 도우미 코드 자체 호스팅
교차 출처 스토리지 액세스를 제거하는 또 다른 방법은 Firebase 로그인 도우미 코드를 자체 호스팅하는 것입니다. 하지만 이 방법은 Apple 로그인이나 SAML에는 작동되지 않습니다. 옵션 3의 역방향 프록시 설정을 실행할 수 없는 경우에만 이 옵션을 사용하세요.
도우미 코드를 호스팅하는 단계는 다음과 같습니다.
다음 명령어를 실행하여 <project>.firebaseapp.com 위치에서 호스팅할 파일을 다운로드합니다.
위 파일을 앱 도메인 아래에서 호스팅합니다. 웹 서버가 https://<app domain>/__/auth/<filename> 및 https://<app domain>/__/firebase/init.json에 응답할 수 있는지 확인합니다.
다음은 파일을 다운로드하고 호스팅하는 샘플 서버 구현입니다.
최신 버그 수정 및 기능이 적용되도록 정기적으로 파일을 다운로드하고 동기화하는 것이 좋습니다.
옵션 1의 단계를 수행하여 승인된 redirect_uri 및 authDomain을 업데이트합니다. 앱을 다시 배포하면 더 이상 교차 출처 스토리지에 액세스할 수 없습니다.
옵션 5: 공급업체 로그인을 개별적으로 처리
Firebase 인증 SDK는 복잡한 로직을 래핑하는 데 편리한 방법으로 signInWithPopup() 및 signInWithRedirect()를 제공하며 다른 SDK를 포함할 필요는 없습니다. 제공업체에 개별적으로 로그인한 후 signInWithCredential()을 사용하여 제공업체의 사용자 인증 정보를 Firebase 인증 사용자 인증 정보로 교환하면 한 메서드를 사용하지 않을 수 있습니다.
예를 들어 Google 로그인 SDK인 샘플 코드를 사용하여 Google 계정 사용자 인증 정보를 가져온 후 다음 코드를 실행하여 새 Google 사용자 인증 정보를 인스턴스화할 수 있습니다.
Web
// `googleUser` from the onsuccess Google Sign In callback.// googUser = gapi.auth2.getAuthInstance().currentUser.get();constcredential=GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);constresult=awaitsignInWithCredential(auth,credential);
Web
// `googleUser` from the onsuccess Google Sign In callback.constcredential=firebase.auth.GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);constresult=awaitfirebase.auth().signInWithCredential(credential);
signInWithCredential()을 호출하면 나머지 앱 기능이 이전과 동일하게 작동합니다.
[null,null,["최종 업데이트: 2025-08-08(UTC)"],[],[],null,["This document describes the best practices for using redirect sign-ins on browsers\nthat block third-party cookies. You must follow one of the options listed here for [`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) to function as intended in production environments, across all browsers.\n| **Note:** Starting June 24 2024, implementing one of the options will be required for redirect sign-in to work on Google Chrome M115+. This is already required on Firefox 109+ and Safari 16.1+.\n\nOverview\n\nTo make the\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) flow\nseamless for you and your users, the Firebase Authentication JavaScript SDK uses a\ncross-origin iframe that connects to your app's Firebase Hosting domain.\nHowever, this mechanism doesn't work with browsers that block third-party\nstorage access.\n\nBecause asking your users to disable storage partitioning features on the browser is rarely an option, you should instead apply one of the following setup options to your app, depending on the specifics of your use case.\n\n- If you host your app with Firebase Hosting on a subdomain of `firebaseapp.com`, you are not affected by this issue and no action is needed.\n- If you host your app with Firebase Hosting on a custom domain or a subdomain of `web.app`, use [Option 1](#update-authdomain).\n- If you host your app with a service other than Firebase, use [Option 2](#signinwithpopup), [Option 3](#proxy-requests), [Option 4](#self-host-helper-code), or [Option 5](#handle-signin-independently).\n\nOption 1: Update your Firebase config to use your custom domain as your `authDomain`\n\nIf you're hosting your app with Firebase Hosting using a custom domain, you can\nconfigure the Firebase SDK to use your custom domain as the `authDomain`. This\nensures that your app and the auth iframe use the same domain, which prevents\nthe sign-in issue. (If you don't use Firebase Hosting, you need to use a\ndifferent option.). Make sure you've set up the custom domain on the same\nproject you are using for authentication.\n\nTo update your Firebase config to use your custom domain as your auth domain, do\nthe following:\n\n1. Configure the Firebase JS SDK to use your custom domain as the `authDomain`:\n\n const firebaseConfig = {\n apiKey: \"\u003capi-key\u003e\",\n authDomain: \"\u003cthe-domain-that-serves-your-app\u003e\",\n databaseURL: \"\u003cdatabase-url\u003e\",\n projectId: \"\u003cproject-id\u003e\",\n appId: \"\u003capp-id\u003e\"\n };\n\n| **Important:** Normally, you should not modify any other field in the Firebase config object. [Learn about the Firebase config object](/docs/web/learn-more#config-object).\n\n1. Add the new `authDomain` to your OAuth provider's list of authorized\n redirect URIs. How you do this will depend on the provider, but in general\n you can follow the \"Before you begin\" section in any provider for exact\n instructions (for example, the\n [Facebook provider](https://firebase.google.com/docs/auth/web/facebook-login)). The updated URI to\n authorize looks like\n `https://\u003cthe-domain-that-serves-your-app\u003e/__/auth/handler` --- the trailing\n `/__/auth/handler` is important.\n\n Similarly, if you're using a SAML provider, add the new `authDomain` to the\n SAML Assertion Consumer Service (ACS) URL.\n2. Make sure your `continue_uri` is in the list of [authorized domains](https://console.firebase.google.com/project/_/authentication/settings).\n\n3. Re-deploy with Firebase Hosting if needed to fetch the most up-to-date Firebase configuration file hosted at `/__/firebase/init.json`.\n\nOption 2: Switch to signInWithPopup()\n\nUse [`signInWithPopup()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithpopup) instead of\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect). The\nrest of your app's code remains the same, but the UserCredential object is\nretrieved differently. \n\nWeb \n\n // Before\n // ==============\n signInWithRedirect(auth, new GoogleAuthProvider());\n // After the page redirects back\n const userCred = await getRedirectResult(auth);\n\n // After\n // ==============\n const userCred = await signInWithPopup(auth, new GoogleAuthProvider());\n\nWeb \n\n // Before\n // ==============\n firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());\n // After the page redirects back\n var userCred = await firebase.auth().getRedirectResult();\n\n // After\n // ==============\n var userCred = await firebase.auth().signInWithPopup(\n new firebase.auth.GoogleAuthProvider());\n ```\n\nPopup sign-in isn't always ideal for users---popups are occasionally blocked by\nthe device or platform, and the flow is less smooth for mobile users. If using\npopups is an issue for your app, you'll need to follow one of the other\noptions.\n\nOption 3: Proxy auth requests to firebaseapp.com\n\nThe `signInWithRedirect` flow starts by redirecting from your app domain to the\ndomain specified in the `authDomain` parameter in firebase config\n(\".firebaseapp.com\" by default). `authDomain` hosts the sign-in helper code that redirects to the Identity Provider, which, on success, redirects back to the app domain.\n\nWhen the authentication flow returns to your app domain, the browser storage of\nthe sign-in helper domain is accessed. This option and the\nfollowing one (to self-host the code) eliminates the cross-origin storage access, which otherwise gets blocked by browsers.\n\n1. Set up a reverse proxy on your app server so that GET/POST requests to\n `https://\u003capp domain\u003e/__/auth/` are forwarded to `https://\u003cproject\u003e.firebaseapp.com/__/auth/`.\n Ensure that this forwarding is transparent to the browser; this cannot be done via a 302 Redirect.\n\n If you are using nginx to serve your custom domain, the reverse-proxy config will look like this: \n\n # reverse proxy for signin-helpers for popup/redirect sign in.\n location /__/auth {\n proxy_pass https://\u003cproject\u003e.firebaseapp.com;\n }\n\n2. Follow the steps in\n [Option 1](#update-authdomain)\n to update authorized `redirect_uri`, ACS URL and your `authDomain`. Once you re-deploy\n your app, the cross-origin storage access should no longer happen.\n\nOption 4: Self-host the sign-in helper code in your domain\n\nAnother way to eliminate the cross-origin storage access is to self-host\nthe Firebase sign-in helper code. However, this approach doesn't work for Apple\nsign-in or SAML. Use this option only if the reverse-proxy setup in\noption 3 is infeasible.\n\nHosting the helper code has the following steps:\n\n1. Download the files to host from the `\u003cproject\u003e.firebaseapp.com` location by\n executing the following commands:\n\n mkdir signin_helpers/ && cd signin_helpers\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/handler\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/handler.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/experiments.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/iframe\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/iframe.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/firebase/init.json\n\n2. Host the above files under your app domain. Ensure that your web server\n can respond to `https://\u003capp domain\u003e/__/auth/\u003cfilename\u003e` and\n `https://\u003capp domain\u003e/__/firebase/init.json`.\n\n Here is a [sample server implementation](https://go.dev/play/p/yvHmY9Bd50N) that downloads and hosts the files.\n We recommend downloading and syncing the files periodically to ensure that the latest bug fixes and features are picked up.\n3. Follow the steps in\n [Option 1](#update-authdomain)\n to update authorized `redirect_uri` and your `authDomain`. Once you re-deploy\n your app, the cross-origin storage access should no longer happen.\n\nOption 5: Handle provider sign-in independently **Important:** This is a complex approach that uses additional SDKs, and potentially can be very involved for SAML providers.\n\nThe Firebase Authentication SDK provides\n[`signInWithPopup()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithpopup) and\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) as\nconvenience methods to wrap complicated logic and avoid the need to involve\nanother SDK. You can avoid using either method entirely by independently signing\nin to your provider, then using\n[`signInWithCredential()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithcredential) to\nexchange the provider's credentials for a Firebase Authentication credential.\nFor example, you can use the\n[Google Sign In SDK](https://developers.google.com/identity/gsi/web/guides/overview),\n[sample code](https://github.com/google/google-api-javascript-client/blob/master/samples/authSample.html)\nto obtain a Google account credential, then instantiate a new Google credential,\nby running the following code: \n\nWeb \n\n // `googleUser` from the onsuccess Google Sign In callback.\n // googUser = gapi.auth2.getAuthInstance().currentUser.get();\n const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);\n const result = await signInWithCredential(auth, credential);\n\nWeb \n\n // `googleUser` from the onsuccess Google Sign In callback.\n const credential = firebase.auth.GoogleAuthProvider.credential(\n googleUser.getAuthResponse().id_token);\n const result = await firebase.auth().signInWithCredential(credential);\n\nAfter you've called `signInWithCredential()`, the rest of your app functions the\nsame as it did before.\n\nInstructions for obtaining an Apple credential are\n[here](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/configuring_your_webpage_for_sign_in_with_apple)."]]
