Firebase Auth: 환경별 제약과 우회 전략

[Firebase Auth로 보는 소셜 로그인: OAuth 2.0 흐름 완전 해부]에서 Oauth 2.0 프로토콜과 Firebase Auth의 인가 과정에 대해 자세히 알아보았습니다.

그러나 실제 서비스 환경에서는 브라우저·앱 내 웹뷰·인앱 브라우저 등 다양한 환경에 따라 저장소 접근 제한, 팝업 차단, OAuth 금지와 같은 여러 제약이 발생합니다.

이번 글에서는 환경별 제약을 살펴보고, 이를 우회할 수 있는 전략을 제시하겠습니다.

1. 인증 과정

먼저 Firebase Authentication이 어떻게 동작하는지 간단히 복습하겠습니다.

1. 사용자가 Client(웹/앱)에서 소셜 로그인 버튼을 클릭합니다.
2. Client는 Authorization Server(예: Google OAuth 2.0 서버)로 리다이렉트합니다.
3. 사용자는 Authorization Server에서 로그인 및 권한 부여를 수행합니다.
4. Authorization Server는 Client의 리다이렉트 URI로 인가 코드를 포함하여 리다이렉트합니다.
5. Client는 인가 코드를 사용하여 Authorization Server로부터 액세스 토큰을 요청합니다.

이 흐름에서 가장 취약한 구간은 4번과 5번 사이입니다. 로그인 과정이 정상적으로 동작하려면 두 가지가 보장되어야 합니다.

1. handler 페이지가 브라우저 저장소(IndexedDB/LocalStorage/쿠키 등)를 사용할 수 있어야 합니다.
2. 리다이렉트로 돌아온 뒤 동일 컨텍스트에서 그 값을 읽을 수 있어야 합니다.

이제부터는 이러한 전제가 깨지는 환경과, 그때 발생하는 문제를 살펴보겠습니다.

2. 환경별 제약

2.1 3rd-party 컨텍스트(크로스-사이트)

authDomain(OAuth 인증 플로우에서 __/auth/handler 페이지가 로드되는 도메인)의 기본값은 <project-id>.firebaseapp.com이며, 서비스 도메인이 app.example.com이라면 둘은 서로 다른 사이트입니다.

리다이렉트 흐름 중 firebaseapp.com → app.example.com과 같이 도메인이 변경되면 브라우저/플랫폼에 따라 브라우저 저장소에 접근할 수 없는 경우가 있습니다.

대다수의 사용자가 쓰는 Safari, Chrome 등의 브라우저는 3rd-party 컨텍스트일 경우 저장소 접근을 차단하기 때문에 이에 대한 해결이 필수적입니다.

• 3rd-party 컨텍스트란?
  “사이트”는 도메인을 기준으로 분류됩니다.
  • top level 도메인: 사용자가 주소창에서 보고 있는 메인 페이지 등록 도메인
  • 1st-party 컨텍스트: 탑레벨 도메인과 같은 도메인인 리소스(ex: iframe, 팝업 등)
  • 3rd-party 컨텍스트: 현재 페이지와 다른 도메인에서 로드되거나 리다이렉트된 리소스

해결 방안

공식 문서에서 제안하는 첫 번째 방법은 Firebase로 앱을 호스팅한 경우, authDomain을 앱 도메인과 일치시키는 것입니다.

이를 통해 1st-party 컨텍스트로 분류되어 브라우저 저장소에 접근이 가능해집니다.

(* 공식 문서에서는 이 외에도 다양한 해결 방안을 제시하고 있습니다.)

2.2 인앱 브라우저(카톡·인스타그램 등)

인앱 브라우저란 앱 내부에서 외부 링크를 띄우는 간이 브라우저(카톡/인스타그램 공유 링크에서 열리는 화면)를 의미합니다.

문제점(Firebase Auth 관점)

• 저장소/쿠키 제약: 인앱 브라우저는 설정에 따라 LocalStorage/IndexedDB/쿠키를 제한하거나 에페메랄(메모리 기반 임시 저장소)로 동작하기 때문에 서비스로 복귀해도 값을 읽을 수 없습니다.
• 팝업·창 간 통신 제한: 팝업 기반 로그인 방식은 window.open/window.opener에 의존하는데, 인앱 브라우저는 팝업을 막거나 opener 접근을 차단하는 경우가 많습니다.

참고.

1. popup: 현재 페이지 유지 + 새 창으로 인증 → opener로 결과 전달
2. redirect: 전체 리다이렉트 → handler가 저장 → 돌아와서 읽기
   두 방식 모두 인앱 브라우저 제약에 취약합니다.

• 스토리지·쿠키 접근 제한: 인앱 브라우저 설정에 따라 저장소에 접근이 불가능할 수 있습니다.
• 에페메랄 저장소: 브라우저가 메모리 기반 임시 저장소로 동작하면 인증 상태를 저장하지 못합니다.
• popup & window.opener 접근 불가: 팝업이 차단되면 로그인 시도가 불가능하며, 제한되지 않더라도 window.opener 참조가 불가능하면 부모 창에 인증 정보를 전달할 수 없습니다.

해결 방안

1. 로그인 단계 분리: 인앱 브라우저 감지 시 외부(시스템) 브라우저에서 OAuth를 시작하고, 완료 후 딥링크/유니버설 링크로 앱/웹에 복귀시킵니다.
2. UX 보완: 인앱 환경 감지 시 “외부 브라우저에서 계속하기” 배너/토스트를 노출하여 유도합니다.

3. 하이브리드 앱(WebView)

앞선 사례들은 설정 조정이나 우회 방법으로 어느 정도 해결할 수 있었습니다.

그러나 하이브리드 앱은 브라우저와는 또 다른 제약이 존재합니다.

3.1 웹 로그인(redirect/popup)이 통하지 않은 이유

핵심은 “handler가 브라우저 저장소에 저장 → 서비스 복귀 후 읽기” 체인이 WebView에서 깨진다는 점입니다. 인앱 브라우저에서 나열한 제약사항(저장소 접근 제한, 팝업 통신 차단) 외에도 근본적으로 Google의 임베디드 WebView OAuth 금지 정책으로 인해 로그인 진입 자체가 실패했습니다.

3.2 해결 방안

Firebase는 iOS와 Android용 네이티브 SDK를 제공합니다. WebView 환경에서는 브라우저 기반 OAuth 플로우가 원천적으로 차단되기 때문에, 네이티브 레벨에서 인증을 처리하는 것이 가장 확실한 방법입니다.

앱 전체를 네이티브로 구현하지 않더라도 최소한 로그인 과정만큼은 네이티브 모듈이 담당하고, 이후 세션이나 토큰을 WebView로 전달하는 방식이 안정적입니다. 이렇게 하면 인증 안정성을 확보하면서도 하이브리드 아키텍처의 장점을 살릴 수 있습니다.

정리하며

Firebase Authentication은 실제 서비스 환경에서는 브라우저 저장소 정책, 인앱 브라우저 제약, WebView의 구조적 한계 등 다양한 변수가 존재합니다. 단순한 설정, 방식 변경만으로는 해결되지 않는 문제도 있기 때문에 로그인 플로우와 환경에 대해 깊이 이해하는 것이 중요합니다.

특히 WebView 기반 하이브리드 앱에서는 웹 방식 로그인의 한계가 뚜렷하므로, 네이티브 SDK를 활용해 인증 단계를 처리하는 것이 가장 확실한 해법입니다.