[트러블슈팅] Firebase 멀티호스팅 리다이렉트 로그인 오류 완벽 해결

계기

앞서 [트러블슈팅] 로그아웃 후 뒤로가기 방지 및 리다이렉트 무한 로딩 해결 트러블슈팅을 통해 Firebase의 리다이렉트 로그인 오류가 배포 사이트에서만 안 생긴다고 생각했고 그럼 테스트 할 수 있는 다른 방법이 없을까? 찾아보았음.
그 결과 Firebase에서 멀티호스팅 설정이 가능하다는 말에 '오! 그렇다면 멀티호스팅으로 개발계 배포하여 테스트를 해서 로그인을 고쳐야겠다'라고 생각하고 멀티호스팅 설정에 돌입함.

멀티호스팅 설정

해당 과정은 AI + 검색 + '나' 이렇게 조합으로 진행했다.

1. Firebase 콘솔에서 dev 사이트를 만들면 firebase.json을 배열 형태로 변경

{
  "hosting": [
    {
      "site": "advent-calendar-68497",
      "public": "dist",
      "rewrites": [{ "source": "**", "destination": "/index.html" }]
    },
    {
      "site": "advent-calendar-68497-dev",
      "public": "dist",
      "rewrites": [{ "source": "**", "destination": "/index.html" }]
    }
  ]
}

2. Firebase 콘솔의 Authentication 설정에서 Authorized Domain에 멀티호스팅 도메인 추가

• 도메인에 추가되어야 사용자가 로그인한 후 리다이렉션할 때 block 되지 않음
• 아니면 block되어서 다시 돌아오지 않음

3. GitHub Actions 자동 배포(선택)

• main 푸시 → 프로덕션 배포 (firebase-hosting-merge.yml)
• dev 푸시 → 개발 배포 (firebase-hosting-dev.yml 신규 생성)

핵심: target 명시 필수

멀티호스팅 환경에서는 target을 명시하지 않으면 어느 사이트에 배포할지 모른다.

- uses: FirebaseExtended/action-hosting-deploy@v0
 with:
    firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_ADVENT_CALENDAR_68497 }}
    channelId: live
    projectId: advent-calendar-68497
    target: advent-calendar-68497-dev  # 반드시 명시

개발계 배포 사이트에서도 동일한 문제 발생

이전과 동일하게 설정하고 멀티호스팅으로 정상적으로 배포했는데 production 배포임에도 불구하고 리다이렉션이 동작 안함
테스트 사이트와 동일하게 리다이렉션 후 돌아오면 로그인 정보가 null로 들어와서 아예 로그인이 안됨

??? 동일한데 왜 안되지???? 뭐가 문제지????

원인 추적

• 다시 이전 트러블슈팅 블로그글 [트러블슈팅] Firebase Authentication 리다이렉트 로그인 시 로그인되지 않고 초기 화면으로 돌아가는 문제 해결에서 찾아보았던 블로그 참고 사이트를 다시 봄
• AI에게 코드도 확인해달라고 했지만 현재 운영계 배포 사이트와 동일한 코드라 해당 코드는 로그인 기능적으로는 문제가 없다고 판단하여 코드 문제는 아닐 것임.

1. AI에게 아래 공식 자료를 주고 물어봄

• 공식자료: 서드 파티 스토리지 액세스를 차단하는 브라우저에서 signInWithRedirect를 사용하기 위한 권장사항
• 내가 놓친게 무엇인지 물어보니 Google Cloude 콘솔에서 dev 사이트 Credential에 추가하지 않아서 그렇다고 답변하여 dev 주소 추가함

참고
구글 OAuth 2.0 자격 증명 생성 및 라우터 핸들러 설정은 구글 클라우드 콘솔에서 발급받은 클라이언트 ID(Client ID)와 비밀번호(Client Secret)를 프로젝트 환경 변수에 등록하고, 인증 완료 후 코드를 반환받을 리디렉션 URI(Redirect URI) 엔드포인트를 구현**

1번 방법은 결론적으로
처참히 실패로 끝남! 여전히 리다이렉트로 로그인 안됨

2. 그래도 문제가 여전해서 아래 블로그의 답변대로 authDomain 변경

• 블로그: Firebase: signInWithRedirect 사용 시 로그인이 되지 않는 문제
• firebaseConfig의 authDomain을 현재 dev 사이트 주소로 아래와 같이 하드코딩하여 수정하여 다시 배포함

기존:
authDomain: 프로젝트ID.firebaseapp.com
수정:
authDomain: 프로젝트ID-dev.firebaseapp.com

2번 방법은 결론적으로

• firebase에서는 1)프로젝트ID-dev.web.app과 2)프로젝트ID-dev.firebaseapp.com 2가지를 배포해주는데
• 1)조소는 로그인 안됨❌
• 2)주소는 로그인 됨⭕️

여기서 다시 Why????? 운영계는 둘 다 되는걸????

3. 그래서 authDomain과 배포 주소가 동일해야 하는지 명확히 알기 위해 authDomain을 web.app 주소로 변경하여 다시 배포

기존:
authDomain: 프로젝트ID-dev.firebaseapp.com
수정:
authDomain: 프로젝트ID-dev.wep.app

3번 방법의 결론

• 가정한대로 web.app에서는 리다이렉트 동작함
• firebaseapp.com은 동작안함
• 결국 authDomain과 사이트 주소가 동일해야 함!

결론: authDomain과 배포 사이트 주소가 동일해야 함

그 이유는 아래와 같다고 함

원인: cross-origin 차단

Chrome M115+, Firefox 109+, Safari 16.1+ 이후 브라우저가 서드파티 스토리지를 차단하면서 Firebase redirect 인증이 깨짐.

authDomain:  advent-calendar-68497.firebaseapp.com
dev 사이트:  advent-calendar-68497-dev.web.app   ← 다른 오리진 → 차단

Firebase는 redirect 처리 시 authDomain의 cross-origin iframe을 사용하는데, 이 두 도메인이 다른 오리진이라 차단됨.

이 시점에서 여기서 앞서 생각한 한 가지의 의문: 왜 main(advent-calendar-68497.web.app)은 되는가?

왜 운영계 주소는 둘 다 되지? authDomain 분명 firebase.com으로 되어 있는데?

Firebase는 호스팅 URL의 prefix가 프로젝트 ID와 동일한 경우 특별 처리를 적용한다.

프로젝트 ID: project-1
→ project-1.web.app       prefix 일치 → 특별 처리 → redirect ✅
→ project-1.firebaseapp.com prefix 일치 → 특별 처리 → redirect ✅
   (authDomain 값에 상관없이 동작)

반면 dev 사이트는 프로젝트 ID와 prefix가 다르다:

프로젝트 ID: project-1
dev 사이트:  project-1-dev.  ← -dev가 붙어 prefix 불일치
→ Firebase 특별 처리 없음
→ authDomain과 완전히 일치하는 URL에서만 redirect 동작
→ 다른 URL은 cross-origin 차단

결론: authDomain을 advent-calendar-68497-dev.firebaseapp.com으로 설정하면 해당 URL로 접속 시에만 redirect 동작.

Firebase에서 동일한 문제 생겼을 때 해결책

1.authDomain을 firebase 배포 주소와 동일하게 변경

2. Google Cloud Console OAuth redirect URI 추가

Google Cloud Console
→ APIs & Services → Credentials
→ OAuth 2.0 Client IDs
→ Authorized redirect URIs → + ADD URI
→ firebase 배포주소.web.app/__/auth/handler
→ firebase 배포주소.firebaseapp.com/__/auth/handler

3. 접속 주소

web.app, firebase.com 중 authDomain에 작성한 사이트 주소로 접속

dev redirect 테스트는 반드시 firebaseapp.com 주소로 접속해야 한다.

느낀 점

이전에는 해당 내용을 빠르게 개발해야 하기도 하고 자세히 보지 않고 넘겼던 것이 다시 돌아왔음을 느낌.
역시 넘기면 다시 문제가 발생하게 되는구나 발생한 문제를 깊게 파보는게 필요함을 뼈저리게 느끼게 됨.

더불어 작성한 코드가 아닌 정책에 의해서도 문제가 발생할 수 있고 이는 AI가 최종적으로 옳은 결론을 찾아주기 어려움을 경험하였음.
많은 에러들을 AI를 통해서 해결할 수 있지만, AI를 활용하면서 스스로도 자료를 찾아보고 해당 자료를 근거로 AI에게 물어보고 직접 문제 원인의 가정을 세우고 테스트하는 과정이 필요한 문제도 있음을 깨닫게 되었음.

특히나 이번 건과 같이 동일한 동작이 아닌 정책에 따라 특별 처리 되는 경우에는 문제의 원일을 파악하기에 헷갈릴 수 있음.
정책은 코드가 아니라 사람에 의해 결정되는 것이기에 나의 역량을 높이는 것도 중요하다고 느꼈음.

혹시나 내용 보시다가 궁금한 점, 헷갈리는 점, 보완할 점이 있다면 댓글로 남겨주면 내용 보완하거나 답변을 남겨드리겠습니다!