WebView 앱에서 구글 로그인이 막히는 이유 — OAuth 정책과 "최소 변경" 대응 방법

React를 WebView에 띄우고 백엔드는 Spring Boot API로 받는 하이브리드 앱을 만들다 보면, 소셜 로그인 단계에서 한 번은 반드시 부딪히는 문제가 있다. 구글 로그인 화면이 WebView 안에서 아예 열리지 않거나 403 disallowed_useragent 로 막히는 것이다.

처음 이 상황을 만나면 “앱 전체를 네이티브로 다시 짜야 하나?” 하는 생각이 들 수 있는데, 결론부터 말하면 그럴 필요 없다. 바꿔야 하는 건 로그인 화면을 띄우는 방식 한 군데뿐이다.

왜 막히는가

구글은 임베디드 브라우저(WebView) 안에서 OAuth 로그인을 수행하는 것을 명시적으로 차단하고 있다. 이유는 보안이다.

WebView는 앱이 완전히 통제하는 브라우저다. 앱 개발자가 마음만 먹으면 사용자가 입력하는 아이디·비밀번호를 가로챌 수 있다.
사용자는 지금 보고 있는 로그인 화면이 진짜 구글 화면인지, 앱이 흉내 낸 피싱 화면인지 구분할 방법이 없다.
주소창이 없으니 URL 확인도 불가능하다.

그래서 구글은 WebView의 User-Agent를 감지해서 OAuth 요청을 거부한다. 이건 우회할 대상이 아니라 정책이다. User-Agent를 바꿔서 뚫는 방법이 인터넷에 돌아다니지만, 정책 위반이고 언제 막혀도 이상하지 않다.

다른 소셜 로그인은?

같은 문제를 겪으면서 Kakao, Naver, Apple도 같이 확인해봤다.

제공자	WebView OAuth
Google	명시적으로 차단 (가장 엄격)
Apple	정책상 시스템 브라우저 권장. Sign in with Apple은 네이티브 SDK 경로가 따로 있음
Kakao	명시적 차단은 없으나 SDK/브라우저 방식 권장
Naver	명시적 차단은 없음

정리하면 지금 당장 막히는 건 구글이지만, 업계 전체 방향은 “OAuth는 앱이 통제하지 않는 브라우저에서 하라”는 쪽으로 일관되게 가고 있다. 구글 때문에 어차피 구조를 바꿔야 한다면, 나머지도 같은 방식으로 맞춰두는 게 나중에 두 번 일하지 않는 길이다.

대응: 로그인 화면만 시스템 브라우저로

핵심은 로그인 페이지를 여는 순간만 WebView 밖으로 빼는 것이다.

Android: Chrome Custom Tabs
iOS: SFSafariViewController (또는 ASWebAuthenticationSession)

이 둘은 시스템 브라우저를 앱 안에 오버레이 형태로 띄워준다. 사용자 입장에서는 앱을 벗어난 것처럼 보이지 않지만, 실제로는 앱이 통제할 수 없는 브라우저이므로 구글 정책을 만족한다. 게다가 브라우저의 기존 로그인 세션을 공유하기 때문에 이미 구글에 로그인돼 있으면 비밀번호를 다시 안 쳐도 된다. 사용자 경험은 오히려 좋아진다.

흐름

[WebView 안 React]
   └─ "구글로 로그인" 버튼 클릭
        └─ JS Bridge로 네이티브 호출
             └─ Chrome Custom Tabs / SFSafariViewController 오픈
                  └─ 사용자 구글 인증
                       └─ redirect_uri 로 콜백 (커스텀 스킴 또는 App Link)
                            └─ 네이티브가 code 수신
                                 └─ WebView / 백엔드로 전달
                                      └─ Spring Boot가 code → token 교환

바뀌는 곳은 딱 하나, “버튼 클릭 → 로그인 페이지 열기” 부분이 window.location 이나 iframe 대신 브릿지 호출로 바뀌는 것이다. 나머지 화면, API, 세션 관리는 그대로다.

콜백 받기

redirect_uri를 앱이 받을 수 있는 주소로 등록해야 한다.

커스텀 URL 스킴: myapp://oauth/callback
Android App Links / iOS Universal Links: https://api.example.com/oauth/callback (더 안전, 설정은 더 번거로움)

구글 클라우드 콘솔에서는 Android/iOS 클라이언트 타입으로 등록하면 패키지명·번들ID 기준으로 검증되므로, 웹 클라이언트 타입으로 등록해놓고 WebView에서 쓰려던 방식과는 애초에 다르다는 점을 기억해야 한다.

백엔드 쪽

Spring Boot에서 code → token 교환을 하는 부분은 WebView 시절과 동일하다. 다만 PKCE를 쓰고 있다면 code_verifier를 만든 주체(네이티브 또는 WebView)와 교환 요청을 보내는 주체가 일치하도록 한 곳에서 관리해야 한다. BFF 패턴이라면 백엔드가 code_verifier를 세션에 들고 있는 게 가장 깔끔하다.

“전면 네이티브 전환”을 선택하지 않은 이유

이 문제를 처음 만났을 때 검토했던 선택지는 세 가지였다.

로그인 호출부만 시스템 브라우저로 교체 (선택)
로그인 화면 전체를 네이티브로 구현
앱 전체를 React Native 등으로 재작성

문제의 범위는 “구글이 WebView 안의 OAuth를 거부한다”는 것 하나다. 이 범위에 맞는 최소 변경은 1번이고, 2·3번은 문제 크기에 비해 변경 범위가 너무 크다. 정책 이슈의 범위가 좁을 때는 그 범위만큼만 손대는 게 맞다. 아키텍처를 갈아엎을 이유는 “구조가 근본적으로 잘못됐다”는 판단이 섰을 때 생기는 것이지, 정책 하나 때문에 생기는 게 아니다.

정리

구글은 WebView 안의 OAuth를 정책으로 차단한다. 우회하지 말 것.
Kakao/Naver는 아직 명시적 차단이 없지만, 방향은 같다.
로그인 페이지를 여는 부분만 Chrome Custom Tabs / SFSafariViewController로 바꾸면 된다.
하이브리드 구조, Spring Boot 백엔드, 세션 관리는 그대로 둔다.