먼저 확인할 핵심
Firebase Auth unauthorized-domain 오류는 로그인 함수가 잘못되어서라기보다, 현재 앱이 열린 도메인과 Firebase Authentication의 승인 도메인 설정이 맞지 않을 때 주로 발생합니다. 로컬에서는 Google 로그인이 되지만 Vercel, Netlify, Firebase Hosting, 개인 도메인에서만 실패한다면 코드 수정 전에 실제 접속 도메인, Firebase 프로젝트, OAuth 제공자 활성화 상태를 먼저 맞춰 봐야 합니다.
- Firebase Auth unauthorized-domain 오류를 먼저 분리하기
- 현재 접속 도메인과 승인 도메인 대조하기
- Firebase Console에서 수정하는 위치
- 코드와 환경변수에서 같이 확인할 부분
- 배포 환경별로 다르게 봐야 하는 케이스
- 다시 확인할 체크포인트
Firebase Auth unauthorized-domain 오류를 먼저 분리하기
Firebase 로그인 오류를 볼 때는 먼저 “로그인 함수 호출이 실패했는지”와 “현재 도메인이 인증 작업을 시작할 수 없는 상태인지”를 분리해야 합니다. auth/unauthorized-domain은 후자에 가깝습니다. Google 로그인 팝업을 열거나 redirect 로그인을 시작하는 순간, Firebase Authentication은 지금 앱이 실행 중인 도메인이 프로젝트의 승인 목록에 있는지 확인합니다.
그래서 이 오류는 로컬 개발 중에는 보이지 않다가 배포 후에 드러나는 일이 많습니다. localhost에서는 로그인이 되는데 my-app.vercel.app, www.example.com, example.com에서만 실패한다면 로그인 버튼 코드만 계속 바꿔도 해결되지 않습니다. 먼저 브라우저 주소창에 표시된 실제 도메인과 Firebase Console의 Authorized domains 목록을 대조해야 합니다.
대표적인 오류 문구는 아래처럼 나타납니다.
Firebase: Error (auth/unauthorized-domain).
This domain is not authorized for OAuth operations for your Firebase project.문구에 OAuth operations가 들어가면 Google, GitHub, Facebook 같은 소셜 로그인 흐름에서 특히 자주 보입니다. 다만 이메일 링크 로그인이나 비밀번호 재설정 링크처럼 actionCodeSettings.url을 쓰는 기능은 continue URL의 도메인을 별도로 검사하며, 이때는 auth/unauthorized-continue-uri 계열 오류로 드러날 수 있습니다. 그래서 OAuth 로그인 도메인 승인과 이메일 action continue URL 승인은 함께 확인하되, 오류 코드와 흐름은 구분해서 봐야 합니다.
여기서 중요한 점은 “로그인이 실패했다”는 결과만 보고 인증 로직 전체를 의심하지 않는 것입니다. 같은 Firebase 설정으로 로컬과 배포 환경의 결과가 다르다면, 대개 실행 도메인이나 배포 환경변수가 먼저 확인 대상입니다.
현재 접속 도메인과 승인 도메인 대조하기
가장 먼저 브라우저 주소창에 보이는 도메인을 그대로 확인합니다. 여기서 자주 놓치는 부분은 루트 도메인과 www 도메인을 같은 것으로 생각하는 점입니다. example.com과 www.example.com은 사용자 눈에는 같은 사이트처럼 보여도, 인증 설정에서는 별도의 호스트로 확인해야 합니다.
| 실제 접속 주소 | 승인 도메인에서 확인할 값 | 확인 포인트 |
|---|---|---|
https://example.com/login |
example.com |
www.example.com만 등록되어 있으면 실패할 수 있습니다. |
https://www.example.com/login |
www.example.com |
루트 도메인만 등록한 상태인지 확인해야 합니다. |
승인 도메인에는 보통 경로까지 넣지 않습니다. https://example.com/login 전체를 복사하는 것이 아니라, 실제 호스트인 example.com을 기준으로 봅니다. 이메일 action의 continue URL도 Firebase 문서에서는 URL 도메인을 승인 목록에 추가하라고 설명하므로, 실제로 돌아오는 URL의 호스트가 무엇인지 먼저 분리해야 합니다. 포트가 붙은 로컬 주소도 마찬가지입니다. 개발 서버가 5173, 3000, 8080처럼 달라도 먼저 확인할 값은 localhost입니다.
다만 최근 생성한 Firebase 프로젝트에서는 localhost가 기본 승인 도메인으로 들어가 있지 않을 수 있습니다. 로컬에서 이메일 링크 로그인이나 OAuth 흐름을 테스트할 예정이라면 Authorized domains에서 localhost가 있는지 직접 확인하는 쪽이 안전합니다. 운영 프로젝트에서는 localhost를 계속 열어둘 필요가 있는지도 따로 판단해야 합니다.
문제가 배포 직후에만 발생한다면 프론트엔드 배포 오류 해결 허브처럼 도메인, 환경변수, 캐시를 함께 보는 체크리스트가 더 빠릅니다. 인증 오류는 코드 한 줄보다 배포 환경에서 바뀐 값 때문에 생기는 경우가 많습니다.
Firebase Console에서 수정하는 위치
수정 위치는 Firebase Console의 Authentication 설정 안에 있습니다. 프로젝트를 잘못 선택하면 아무리 도메인을 추가해도 앱에는 반영되지 않으므로, 먼저 현재 앱의 projectId와 Console에서 열어둔 프로젝트가 같은지 확인합니다.
- Firebase Console에서 현재 앱이 연결된 프로젝트를 엽니다.
Security또는Build영역의Authentication메뉴로 이동합니다.Settings탭에서Authorized domains영역을 찾습니다.- 현재 로그인 페이지가 실제로 열리는 도메인을 추가합니다.
- Google 로그인을 사용한다면
Sign-in method에서 Google provider가 활성화되어 있는지도 확인합니다.
여기서 추가해야 하는 값은 “내가 접속했으면 하는 도메인”이 아니라 “브라우저가 실제로 열고 있는 도메인”입니다. DNS를 방금 바꿨거나 리다이렉트 설정을 수정한 상태라면 주소창에서 최종적으로 남는 도메인을 기준으로 판단해야 합니다. example.com으로 접속했지만 자동으로 www.example.com으로 이동한다면, 로그인은 www.example.com에서 시작됩니다.
반대로 www에서 루트 도메인으로 리다이렉트되는 구조라면 example.com을 확인해야 합니다. 둘 다 실제 접근 경로로 열릴 수 있다면 둘 다 등록해 두는 편이 배포 직후의 혼선을 줄입니다. 단, 더 이상 사용하지 않는 테스트 도메인이나 예전 배포 도메인은 정리해야 합니다.
코드와 환경변수에서 같이 확인할 부분
도메인을 추가했는데도 같은 오류가 계속 보인다면 코드 쪽에서는 Firebase 앱 설정을 확인합니다. 특히 개발용 Firebase 프로젝트와 운영용 Firebase 프로젝트를 나눠 쓰는 경우, Console에서는 운영 프로젝트를 수정했는데 앱은 개발 프로젝트의 apiKey, authDomain, projectId를 바라보고 있을 수 있습니다.
const firebaseConfig = {
apiKey: import.meta.env.VITE_FIREBASE_API_KEY,
authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN,
projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID,
};Vite 기반 React 프로젝트라면 위처럼 import.meta.env를 사용합니다. Next.js 프로젝트라면 브라우저에서 접근해야 하는 값에는 NEXT_PUBLIC_ 접두사가 붙어야 합니다. 이 차이를 놓치면 로컬에서는 값이 들어온 것처럼 보이다가 배포 환경에서 다른 Firebase 프로젝트를 바라보거나, 인증 초기화 자체가 엉뚱하게 구성될 수 있습니다.
환경변수를 쓰고 있다면 배포 서비스의 설정도 같이 봐야 합니다. 로컬의 .env.local만 바꾸고 Vercel이나 Netlify의 Environment Variables를 수정하지 않으면, 배포된 앱은 여전히 이전 Firebase 프로젝트를 사용합니다. 이 상태에서는 Authorized domains를 올바른 프로젝트에 추가해도 실행 중인 앱과 설정을 수정한 프로젝트가 달라서 증상이 그대로 남습니다.
Google 로그인 코드 자체는 아래처럼 단순할 수 있습니다. 이 코드가 로컬에서는 동작하고 배포에서만 실패한다면 함수 구조보다 실행 도메인과 프로젝트 설정을 먼저 확인해야 합니다.
import { GoogleAuthProvider, signInWithPopup } from 'firebase/auth';
const provider = new GoogleAuthProvider();
export async function signInWithGoogle(auth) {
return signInWithPopup(auth, provider);
}이메일 링크 로그인에서는 actionCodeSettings.url도 빠뜨리기 쉽습니다. 로그인 링크가 최종적으로 돌아올 URL의 도메인이 승인 도메인 목록에 있어야 합니다.
const actionCodeSettings = {
url: 'https://example.com/auth/finish',
handleCodeInApp: true,
};위 예시라면 example.com이 Authorized domains에 있어야 합니다. auth/unauthorized-domain을 Google 로그인 문제로만 생각하면 이메일 링크, 비밀번호 재설정, 인증 메일 리다이렉트에서도 같은 실수를 반복하기 쉽습니다.
배포 환경별로 다르게 봐야 하는 케이스
Vercel이나 Netlify를 쓰면 production 도메인과 preview 도메인이 나뉩니다. 운영 사이트는 example.com으로 열리지만, PR 확인용 preview는 feature-login-my-app.vercel.app처럼 다른 도메인으로 열릴 수 있습니다. preview 환경에서도 실제 로그인을 테스트하려면 그 도메인까지 승인 목록에 넣어야 합니다.
다만 preview URL이 계속 바뀌는 팀에서는 모든 임시 도메인을 무작정 추가하는 방식이 관리하기 어렵습니다. 이 경우 preview에서는 로그인 전체 플로우를 제한하거나, 고정된 preview 도메인을 쓰거나, production과 동일한 인증 테스트가 필요한 시점에만 도메인을 추가하는 식으로 운영 기준을 정해야 합니다.
Firebase Hosting을 쓰는 경우에는 기본 도메인과 커스텀 도메인을 구분해서 봅니다. project-id.web.app에서 테스트할 때와 example.com에서 테스트할 때의 접속 도메인이 다르기 때문에, 실제 로그인 버튼을 누르는 주소를 기준으로 등록해야 합니다. 커스텀 도메인을 연결한 직후에는 DNS 전파와 SSL 인증서 준비 시간이 겹칠 수 있으므로, 도메인 연결 상태와 인증 오류를 분리해서 확인해야 합니다.
signInWithRedirect를 쓰는 앱이라면 unauthorized-domain과 redirect 브라우저 이슈도 구분해야 합니다. 승인 도메인이 맞는데 특정 브라우저에서만 redirect 로그인 후 상태가 돌아오지 않는다면, 그때는 도메인 승인 문제보다 redirect 흐름과 브라우저 저장소 정책을 따로 봐야 합니다. Firebase Hosting 커스텀 도메인을 authDomain으로 쓰는 구조라면 같은 프로젝트의 Hosting 도메인인지 확인하고, OAuth 제공자 쪽 redirect URI에는 /__/auth/handler 경로까지 포함된 주소가 등록되어야 합니다.
로그인까지는 통과했는데 Firestore 읽기나 쓰기에서 막힌다면 원인이 달라집니다. 그때는 Authorized domains가 아니라 Security Rules와 인증 상태를 봐야 하므로 Firestore permission-denied 오류 해결처럼 권한 규칙 쪽으로 범위를 옮겨 확인하는 편이 맞습니다.
다시 확인할 체크포인트
Firebase Auth unauthorized-domain 오류는 로그인 버튼 코드만 보면 해결이 늦어집니다. 먼저 브라우저 주소창의 실제 도메인을 확인하고, 그 도메인이 현재 앱이 연결된 Firebase 프로젝트의 Authorized domains에 있는지 대조해야 합니다.
그다음에는 루트 도메인과 www 도메인을 분리해서 보고, 배포 서비스의 기본 도메인과 개인 도메인을 따로 확인합니다. 로컬 개발 환경이라면 localhost가 승인 목록에 있는지도 직접 확인합니다. 최근 생성한 프로젝트에서는 로컬 도메인을 기본값으로 기대하지 않는 편이 낫습니다.
마지막으로 환경변수와 Firebase 프로젝트 선택을 맞춰 봅니다. Console에서 수정한 프로젝트와 실제 앱이 사용하는 projectId가 다르면 설정을 바꿔도 증상이 그대로 남습니다. 같은 오류를 다시 만나면 코드 수정부터 들어가기보다, 현재 도메인 → Firebase 프로젝트 → Authorized domains → provider 활성화 → 배포 환경변수 순서로 좁혀가면 원인을 더 빠르게 찾을 수 있습니다.
참고 기준은 Firebase 공식 문서의 Google 로그인 설정, 이메일 action continue URL, signInWithRedirect 브라우저 저장소 대응, Firebase Auth Web SDK 오류 코드를 함께 확인하면 됩니다.