Inicio de sesión con Google y Sign in with Apple en una app WebView: el flujo de Codex para Firebase Auth
Hay dos cosas que rompen el login en una app web empaquetada: Google rechaza OAuth dentro de WebViews embebidos, y Apple rechaza las apps que ofrecen Google sin una alternativa respetuosa con la privacidad. WebViewGold resuelve lo primero de forma nativa y detecta Sign in with Apple automáticamente en iOS; Codex adapta el lado web. Esta guía usa Firebase Auth en una app alojada con Express, el stack en el que los detalles de la redirección importan más.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
Garantía de aprobación – o te devolvemos el dinero en 14 días
Sin programar
Pago único, actualizaciones gratuitas
Soporte humano 24/7
Hecho en Alemania desde 2014 · ISO 27001
9:41
Tu app
Tu appYa en tu bolsillo
App Store · Google Play Aprobada
El objetivo y la prueba de diez segundos del revisor
El objetivo son tres opciones de inicio de sesión que funcionen dentro de las apps de iOS y Android exactamente igual que en la web: email, Google y Sign in with Apple, todas terminando en la misma sesión de Firebase dentro del WebView, y que sigan ahí después de cerrar y volver a abrir la app.
La prueba del revisor es corta. Toca Google; si Google responde con "Error 403: disallowed_useragent", la app está rota (Directriz 2.1). Busca una opción de Apple junto a la de Google; si falta, la Directriz 4.8 exige una opción de inicio de sesión que limite los datos al nombre y al email y permita ocultar la dirección, lo que en la práctica significa Sign in with Apple. Las apps que solo usan sus propias cuentas con email o magic link están exentas, y esa es una salida legítima (la Directriz 4.8 en detalle).
Google bloquea OAuth en los WebViews embebidos. Cuando se carga una URL de google_login_helper_triggers (Config.swift), WebViewGold abre el inicio de sesión en una ventana propia con un user agent que Google acepta y después vuelve a tu app; Android tiene la misma lista como GOOGLE_LOGIN_HELPER_TRIGGERS en Config.java, además de las listas de Facebook. Sign in with Apple (appleid.apple.com) se gestiona automáticamente en iOS. Consulta la documentación de inicio de sesión social.
Tu app web: redirección en tu propio dominio
Safari y otras vistas WebKit bloquean el almacenamiento de terceros, lo que rompe el inicio de sesión por redirección de Firebase mientras authDomain siga apuntando a PROJECT.firebaseapp.com. Las buenas prácticas de Firebase para la redirección enumeran varias soluciones; para una app en Express, la más limpia es un proxy inverso para /__/auth/ en tu dominio y authDomain configurado con ese dominio.
Apple Developer: Services ID y clave
Un Services ID con tu dominio y la URL de retorno https://app.example.com/__/auth/handler (tu dominio, por el proxy), una clave de Sign in with Apple y tu Team ID, todo introducido en el proveedor de Apple de Firebase.
Android: Apple es opcional
Google Play no tiene ninguna regla sobre Sign in with Apple. Muestra el botón en Android solo si tus usuarios lo esperan, y prueba esa redirección en un dispositivo; la gestión automática de Apple de WebViewGold está documentada para iOS.
La sección de autenticación para AGENTS.md
Añade esto debajo del contexto de ejecución en tu AGENTS.md. Bloquea las tres cosas que suelen hacer los agentes cuando el login falla en un WebView: cambiar el user agent, abrir OAuth en una ventana nueva o quitar Google sin decir nada de la build de iOS. Puedes dejarla en inglés: Codex la entiende igual de bien.
markdown
## Authentication (Firebase Auth inside WebViewGold)
- Providers: email/password, Google, Apple. Google and Apple buttons live in one
component (src/components/SocialButtons.tsx) with equal size and prominence.
- Every sign-in call goes through src/lib/auth.ts. Inside the native app
(isNativeApp()) use signInWithRedirect, which Firebase recommends on mobile;
keep the method in one constant so we can switch to popup after device tests.
Desktop browsers may use signInWithPopup.
- authDomain is our own domain (app.example.com). Express proxies /__/auth/* to
PROJECT_ID.firebaseapp.com as a transparent reverse proxy. Never point
authDomain back to firebaseapp.com.
- Google inside the app works through WebViewGold's Social Login Helper
(google_login_helper_triggers / GOOGLE_LOGIN_HELPER_TRIGGERS). Do not change the
user agent, do not open OAuth URLs with window.open, do not use googlelogin://
unless explicitly asked.
- Sign in with Apple (appleid.apple.com) is handled by WebViewGold on iOS.
- Apple shares the name only on the first sign-in: write displayName to users/{uid}
immediately. Expect @privaterelay.appleid.com addresses.
- auth/account-exists-with-different-credential: ask the user to sign in with the
existing method, then linkWithCredential. Never create a second account silently.
Mi WebView de iOS finalmente está aprobada. ¡Gracias!
Ejecútalo en el repositorio de la app web con codex --sandbox workspace-write --ask-for-approval on-request. Solo cambia código; todo lo que tienes que pulsar en las consolas de Apple y Firebase acaba en un archivo de configuración para ti.
Pégalo en Codex (CLI o extensión del IDE)
Lee AGENTS.md, sobre todo la sección Authentication. Nuestra app usa Firebase Auth con email/contraseña y Google. Apple rechazó la build de iOS por la Directriz 4.8, y el inicio de sesión con Google falla dentro de la app en algunos dispositivos con disallowed_useragent. Arregla el lado web; yo me encargo de las consolas de Apple Developer y Firebase y de la configuración de WebViewGold.
1. Añade Sign in with Apple con new OAuthProvider("apple.com") y los scopes email y name, pasando por src/lib/auth.ts. El botón sigue las directrices de diseño de Apple (negro o blanco, logotipo de Apple, "Sign in with Apple") y tiene el mismo tamaño y protagonismo que el botón de Google.
2. Dentro de la app nativa (isNativeApp()), usa signInWithRedirect y gestiona getRedirectResult al arrancar la app, incluidos los errores, con un mensaje visible en lugar de un fallo silencioso. Mantén el flujo con popup para los navegadores de escritorio. Pon la elección del método en una sola constante.
3. Haz que authDomain sea nuestro propio dominio: añade un proxy inverso en Express que reenvíe /__/auth/ a https://PROJECT_ID.firebaseapp.com (un proxy transparente, no una redirección; conserva rutas, query strings y cookies). Lee PROJECT_ID y el dominio de autenticación de variables de entorno.
4. En el primer inicio de sesión con Apple, escribe displayName y email en users/{uid} si están vacíos.
5. Gestiona auth/account-exists-with-different-credential con un flujo de vinculación: explica qué método usa la cuenta, inicia sesión con él y después llama a linkWithCredential.
6. Escribe SETUP-AUTH.md con lo que debo configurar: el Services ID de Apple con el dominio app.example.com y la URL de retorno https://app.example.com/__/auth/handler, la clave y el Team ID para Firebase, los dominios autorizados en Firebase y los ajustes de WebViewGold que hay que revisar (google_login_helper_triggers en Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS en Config.java, deletecache desactivado).
7. Tests: tests unitarios para el flujo de vinculación, la gestión de errores de la redirección y la ruta del proxy con un upstream simulado. No llames a Google ni a Apple.
Informa de los archivos modificados y de una matriz de pruebas en dispositivo para iOS y Android.
El lado de WebViewGold
Estos son los valores por defecto documentados. Amplía las listas solo si tu inicio de sesión pasa por otros hosts de Google o Facebook (inicia el login en un navegador de escritorio y observa las redirecciones). En Android, los mismos prefijos van en GOOGLE_LOGIN_HELPER_TRIGGERS y FACEBOOK_LOGIN_HELPER_TRIGGERS en Config.java.
swift
// Config.swift: Social Login Helper triggers (documented defaults)
var google_login_helper_triggers: [String] = ["https://accounts.google.com", "https://accounts.youtube.com"]
var facebook_login_helper_triggers: [String] = ["https://m.facebook.com", "https://www.facebook.com"]
// Sign in with Apple (appleid.apple.com) needs no trigger: WebViewGold handles it on iOS.
// Keep sessions across launches: leave deletecache and deletecacheonexit off,
// or users are logged out every time they open the app.
// Custom user agent (useragent_iphone / useragent_ipad): append your marker to the
// default string instead of replacing it.
Orden de trabajo
Cuenta de Apple Developer
Activa Sign in with Apple en el App ID, crea un Services ID, registra app.example.com y la URL de retorno https://app.example.com/__/auth/handler, crea una clave de Sign in with Apple y apunta el Key ID y el Team ID.
Consola de Firebase
Activa el proveedor de Apple (Services ID, Team ID, Key ID, clave privada) y el de Google. Añade app.example.com a los dominios autorizados.
Lanza la tarea de Codex y revísala
Pega el prompt, ejecuta /review en la CLI y lee el git diff. Revisa primero el proxy: tiene que reenviar, no redirigir, y no debe tocar otras rutas.
Despliega y comprueba el handler
Abre https://app.example.com/__/auth/handler en un navegador. Debería servirse desde tu dominio, en lugar de devolver un 404 o rebotar a firebaseapp.com.
Configuración nativa
Confirma las listas de triggers, deja deletecache desactivado en iOS y CLEAR_CACHE_ON_STARTUP desactivado en Android y, si defines un user agent personalizado, añádelo al final de la cadena por defecto. En Android, HOME_URL_LOGOUT puede apuntar a tu URL de cierre de sesión para borrar las cookies del login.
Matriz de dispositivos y, después, el envío
Recorre la matriz de abajo en TestFlight y en una pista de pruebas internas. En las notas para la revisión, enumera las opciones de inicio de sesión y dale al revisor una cuenta demo con email (el flujo de publicación con Codex cubre el resto del envío).
Matriz de pruebas en dispositivo
iOS, nuevo usuario de Apple: el nombre se guarda, se acepta una dirección de retransmisión privada y el usuario entra con la sesión iniciada.
iOS, usuario de Apple que vuelve: la misma cuenta, sin duplicados.
iOS y Android, Google: sin disallowed_useragent, el flujo vuelve a la app con la sesión iniciada.
El email y la contraseña siguen funcionando, y la cuenta demo del revisor funciona al primer intento.
Una cuenta existente con otro proveedor lanza el flujo de vinculación, no una segunda cuenta.
Cierra y vuelve a abrir la app: la sesión sigue iniciada.
Cierra sesión y vuelve a entrar con Google: aparece el selector de cuentas en lugar de un inicio de sesión silencioso en la cuenta anterior.
Trampas habituales
authDomain sigue en firebaseapp.com. La redirección se completa, pero la app suele acabar otra vez en la pantalla de inicio de sesión sin usuario.
Una URL de retorno en el Services ID que no coincide exactamente: http en lugar de https, una barra al final o el host firebaseapp.com después de haberte pasado a tu propio dominio.
Un botón de Apple más pequeño o escondido debajo del botón de Google. Las directrices de diseño de Apple piden el mismo protagonismo, y los revisores comparan.
Direcciones de retransmisión privada que nunca reciben tus emails. Registra tu dominio de envío en Sign in with Apple for Email Communication en tu cuenta de Apple Developer.
Codex propone sustituir el user agent de la app por una cadena de Chrome de escritorio. Rompe los diseños móviles y no hace falta; el Social Login Helper es la vía admitida.
googlelogin:// como opción por defecto. Pasa el inicio de sesión al navegador del sistema en iOS y a una Chrome Custom Tab en Android, así que la sesión vive fuera de tu WebView salvo que tu redirección la traiga de vuelta. Resérvalo para casos especiales (documentación de gestión de URLs en Android).
Preguntas frecuentes
¿Hay que configurar WebViewGold para Sign in with Apple?
En iOS no: el flujo de appleid.apple.com se detecta y se gestiona automáticamente. Tú configuras Apple en tu cuenta de Apple Developer y en Firebase, y añades el botón a tu app web.
¿Necesito Sign in with Apple en Android?
No. Google Play no tiene una regla así. Muchas apps lo muestran en las dos plataformas por coherencia; si lo haces, prueba el flujo en un dispositivo Android antes de publicar.
¿Popup o redirección dentro de la app?
Empieza con la redirección en tu propio authDomain, que es lo que Firebase recomienda en móvil. Deja la elección en una sola constante para poder cambiar a popup si una prueba en dispositivo muestra un problema, y vuelve a probar las dos plataformas después de cualquier cambio.
¿Puede Codex probar él mismo el flujo de OAuth?
No. OAuth necesita cuentas reales en los proveedores, y el sandbox de Codex no tiene acceso a la red por defecto. Codex puede probar la lógica de vinculación, los mensajes de error y la ruta del proxy con mocks; los inicios de sesión reales van en tu matriz de dispositivos.
¿Qué cambia si uso Supabase en lugar de Firebase?
El lado de WebViewGold es idéntico. En Supabase activas el proveedor de Apple con el Services ID y un client secret generado a partir de tu clave (Apple lo limita a seis meses, así que planifica la rotación), y la URL de callback es el auth callback de tu proyecto de Supabase. No hay que construir ningún proxy de authDomain.
Tres formas de llevar tu app a las tiendas
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
Hazlo tú mismo
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.
