Una ID de cliente de Google OAuth es el identificador público de la app que Google muestra como una cadena que termina en .apps.googleusercontent.com. Lo creas y gestionas en Consola de Google Cloud en Google Auth Platform > Clients o APIs y servicios > Credenciales. Ese valor le indica a Google qué app registrada está iniciando Sign in with Google o solicitando tokens de OAuth.
Probablemente estás aquí porque la integración con Google Sign-In debería haber sido rápida, pero en cambio te quedas mirando la pantalla de credenciales preguntándote por qué un tipo de app te da un client secret y otro no. Esa confusión es normal, especialmente si estás construyendo con Capacitor, Ionic, Electron o un stack mixto web y nativo.
Lo que la mayoría de las guías omiten es lo que rompe las implementaciones reales: Los Client IDs de Google son específicos de la plataforma, y los tipos de app no web a menudo no obtienen un client secret por diseño. Si creas la credencial equivocada solo para forzar un secret en el flujo, normalmente terminas con una configuración de OAuth rota que es más difícil de depurar de lo que debería ser.
Tabla de contenidos
- Prerrequisito: pantalla de consentimiento de OAuth
- Cómo crear un client ID de OAuth 2.0
- Dónde encontrar un client ID existente
- Client ID frente a client secret
- Qué es un Google Client ID
- Configuraciones de Client ID por plataforma
- Cómo proteger tus credenciales de Google API
- Solución de errores comunes de Client ID
- FAQ
Prerrequisito: pantalla de consentimiento de OAuth
Antes de que Google te permita crear clientes OAuth, el proyecto debe registrar la app para Google Auth. Google te pedirá completar esto cuando abras Plataforma de Google Auth > Clientes por primera vez.
Pasos típicos:
- Abrir Consola de Google Cloud y selecciona el proyecto que gestionará el inicio de sesión.
- Ve a Plataforma de Google Auth (o APIs & Services > Pantalla de consentimiento de OAuth en la navegación anterior).
- Elige Externo o Interno tipo de usuario, luego completa el nombre de la app, el correo de soporte y el contacto del desarrollador.
- Añade los scopes que tu app solicitará (para el inicio de sesión básico,
emailyprofileson comunes). - Guarda y continúa con el flujo de la pantalla de consentimiento hasta que la app esté registrada.
El nombre de la aplicación en esta pantalla es lo que ven los usuarios en el prompt de permisos de Google. Debe coincidir con la app que instalaron, no con un nombre interno.
Cómo crear un client ID de OAuth 2.0
Google documenta el flujo en la Gestión de clientes OAuth página de ayuda. Ambos puntos de entrada funcionan:
- Plataforma de autenticación de Google > Clientes (luego CREAR CLIENTE)
- APIs y servicios > Credenciales (luego Crear credenciales > ID de cliente OAuth)
Selecciona o crea primero un proyecto de Cloud. No disperses las credenciales de autenticación entre proyectos no relacionados.
Cliente de aplicación web
Usa este tipo para aplicaciones de navegador y para el ID de cliente web muchos SDKs móviles esperan como audiencia de servidor.
- Haz clic CREAR CLIENTE (o crea un ID de cliente OAuth desde Credenciales).
- Elige Aplicación web como tipo de aplicación.
- Configurar Orígenes de JavaScript autorizados a cada origen que ejecuta tu interfaz de inicio de sesión (el esquema, el host y el puerto deben coincidir exactamente). Usa
http://localhost:<port>para desarrollo local. Los orígenes de producción deben usar HTTPS, excepto localhost, según las reglas de Google. - Configurar URIs de redirección autorizadas a cada URL de callback que use tu servidor o SPA después de que Google redirija de vuelta.
- Haz clic Crear. Copia el ID de cliente y guarda el Client secret de forma segura. Google puede mostrar el secreto solo una vez.
En apps híbridas de Capacitor, el Web client ID suele respaldar la verificación de tokens, incluso cuando el inicio de sesión se realiza mediante SDK nativos. Ver Cómo iniciar sesión con Google usando Capacitor para la configuración móvil completa.
Cliente de Android (package name y SHA-1)
Los clientes OAuth de Android vinculan Google Sign-In con tu nombre del paquete y la SHA-1 del certificado de firma.
-
Haz clic CREAR CLIENTE y elige Android.
-
Introduce el Nombre del paquete de tu app (por ejemplo
com.example.app, que coincida conapplicationIden Gradle). -
Obtén el huella digital del certificado SHA-1 del keystore que firma el build que estás probando:
keytool -list -v -keystore path-to-debug-or-production-keystore -alias your-key-aliasPara el keystore de depuración predeterminado, Google indica que la contraseña suele ser
androidy la ruta es comúnmente~/.android/debug.keystore. -
Pega el SHA-1 en el formulario y haz clic en Crear.
-
Copiar Android ID de cliente. Google normalmente no necesitas emitir un client secret para este tipo.
Si la app está en Google Play, registra también el Firma de apps de Play SHA-1 de Play Console Integridad de la app. Play vuelve a firmar las versiones con una clave distinta a la de tu upload keystore.
cliente de iOS (bundle ID)
- Haz clic CREAR CLIENTE y elige iOS.
- Introduce el ID del Bundle desde Xcode (el mismo valor que
CFBundleIdentifierenInfo.plist, por ejemplocom.example.app). - Agrega opcionalmente ID de App Store y ID de equipo cuando Google lo solicite.
- Haz clic Crear y copia el iOS ID de cliente.
Usa este cliente con Google Sign-In nativo para iOS o con @capgo/capacitor-social-login cuando configuras los proveedores de Apple y Google para Capacitor.
Esta guía es una buena referencia visual si quieres comparar la interfaz mientras haces clic:
Dónde encontrar un client ID existente
Después de crearlo, abre Google Auth Platform > Clients o APIs y servicios > Credenciales. Cada fila lista los IDs de cliente OAuth 2.0 por nombre y tipo. Abre un cliente para copiar su ID de cliente cadena (xxxx.apps.googleusercontent.com). Los clientes web también muestran Client secret gestión en la misma página de detalles.
La pantalla de consentimiento no es decoración. Es parte del límite de confianza. Los usuarios ven ahí el nombre de tu aplicación, no el apodo interno de tu proyecto.
Client ID frente a client secret
| Credencial | Quién lo ve | Uso típico |
|---|---|---|
| ID de cliente | Público. Seguro para incrustar en apps y frontends. | Identifica tu app ante Google en cada flujo OAuth. |
| Client secret | Confidencial. Solo servidor o CI. | Demuestra que tu backend posee el cliente OAuth web durante el intercambio de code-for-token. |
Google clasifica Aplicación web los clientes que se ejecutan en tus servidores como privados clientes que pueden usar un secreto. Android, iOS, y otros instalado los clientes son público clients. Google omite intencionalmente un secret porque los usuarios pueden extraer cualquier cosa incluida en un APK o IPA.
No crees un cliente Web para una app móvil solo para obtener un secret. Esa discrepancia causa invalid_client, DEVELOPER_ERROR y errores confusos de audiencia del token más adelante.
Qué es un Google Client ID
Una Client ID de Google OAuth 2.0 es el identificador público de tu aplicación en el sistema de autenticación de Google. Google lo describe como el nombre de usuario único de una aplicación al solicitar access tokens desde sus endpoints de autenticación, y señala que es distinto de las claves API porque se usa en los flujos de OAuth para verificar la identidad de la app durante el intercambio de tokens, como se explica en la documentación de clientes OAuth de Google Cloud.
Piensa en el client ID de Google problemas en tu app nombre de usuario público.
Le dice a Google: "esta solicitud proviene de esta aplicación registrada". Eso importa durante el inicio de sesión, el consentimiento, el intercambio de tokens y cualquier flujo en el que tu app pida actuar en nombre de un usuario. El client ID está pensado para que lo referencien tanto tu app como los servidores de autenticación de Google.
Lo que suele confundir es que esta credencial convive con otros dos conceptos que no son intercambiables.
ID de cliente identifica la app en OAuth.
clave de API identifica un proyecto para ciertas llamadas de API que no implican autorización delegada de usuario.
Client secret es la contraparte confidencial que solo se usa en flujos y tipos de app que pueden guardar secretos con seguridad.
Muchas integraciones rotas empiezan cuando alguien trata estos elementos como variaciones de lo mismo. No lo son.
Si necesitas Iniciar sesión con Google o One Tap, el client ID es el valor que tu frontend utiliza para iniciar el handshake de autenticación. La documentación de Google también señala que la app debe estar registrada en un proyecto dedicado de Cloud Console antes de poder generar la credencial, y que las apps web requieren orígenes JavaScript autorizados o URIs de redirección configurados con el esquema y el hostname completos.
Para equipos que construyen apps híbridas, el modelo mental más seguro es este:
- Usa el client ID para identificar la app
- Usa la pantalla de consentimiento para presentar la app al usuario
- Usa el tipo de app correcto para determinar si un secret debe formar parte del flujo
Si buscas una guía más amplia sobre cómo encajan la identidad de apps y el acceso delegado, esta guía de autorización de apps es un buen repaso. Para OAuth2 de extremo a extremo en Capacitor, consulta OAuth2 en apps de Capacitor.
Configuraciones de Client ID por plataforma
La forma más rápida de romper el login de Google es asumir que un solo client ID sirve para todas las plataformas. No es así. En apps multiplataforma, cada plataforma debe registrar su propio client ID de OAuth 2.0, y la configuración de Android requiere específicamente el fingerprint SHA1 para verificar la propiedad, como se indica en las instrucciones de Google para clientes Android.
Tu producto puede ser una sola app para el usuario, pero para Google son varios clientes OAuth.
Una web app, una Build de Android, una Build de iOS, y un app de escritorio no ofrecen las mismas propiedades de seguridad. Google lo resuelve dando a cada plataforma su propio modelo de registro de aplicaciones.
Esta es la división práctica que debes seguir:
- Web usa un client ID web con coincidencia estricta de origen y redirect URI.
- Android usa un client ID de Android vinculado a la identidad del paquete y al fingerprint SHA1.
- iOS usa un client ID de iOS vinculado al bundle ID de la app.
- Desktop o Electron suele utilizar un patrón OAuth instalado o de escritorio en lugar de un flujo de navegador basado en secretos.
Comparativa de tipos de Google Client ID
| Tipo de aplicación | Identificador principal | ¿Incluye Client Secret? | Caso de uso clave |
|---|---|---|---|
| Web | Orígenes de JavaScript autorizados y URIs de redirección | Normalmente, sí | Apps de navegador y OAuth web asistido por backend |
| Android | Identidad del paquete más huella SHA1 | A menudo, no | Inicio de sesión nativo en Android |
| iOS | Identidad del bundle de la app | A menudo no | Inicio de sesión nativo para iPhone y iPad |
| Escritorio | Identidad de la app instalada | A menudo no | Apps de escritorio, incluidos flujos nativos tipo Electron |
La paradoja del client secret en móvil y desktop
Los desarrolladores de móvil y escritorio suelen esperar que cada cliente OAuth incluya tanto un client ID y un client secret. Luego crean una Aplicación web credencial porque es la única forma de ver un secreto en la consola.
Según la guía de clientes OAuth de Google, los tipos de aplicación no web, como Android, iOS y aplicaciones instaladas, a menudo reciben un client ID pero no un client secret intencionalmente, porque Google no quiere que un secreto confidencial esté incrustado en software de lado cliente donde los usuarios puedan extraerlo.
Para los equipos de Capacitor, esto suele manifestarse en uno de dos patrones problemáticos:
- La app inicia un flujo basado en navegador usando un client web y luego intenta comportarse como un servidor confidencial.
- La app envía un client secret desde code empaquetado, lo cual anula el propósito de tener un secreto.
El mejor enfoque es tratar las apps móviles y de escritorio como clientes públicos. Si tu backend está involucrado, mantén las operaciones confidenciales en el backend y limita la app nativa a lo que un cliente público debería hacer.
Otro punto sutil importa para el inicio de sesión en Android con Firebase. En esa configuración, el client ID de tipo aplicación web se usa como el OAuth client ID del servidor backend, mientras que la app de Android mantiene su propia identidad específica de la plataforma. Cumplen roles diferentes.
Si recuerdas una regla, usa esta: elige el tipo de cliente que coincida con donde se ejecuta code, no con la forma de credencial que desearías tener.
Cómo proteger tus credenciales de Google API
La mayoría de los incidentes de OAuth no son causados por ataques complejos. Los equipos filtran credenciales, amplían demasiado las configuraciones de redirección o colocan secretos en lugares donde nunca fueron seguros.
La guía de OAuth de Google trata los client secrets como credenciales confidenciales que pertenecen en servidores que controlas. IDs de cliente son identificadores públicos, pero aun así debes registrarlos con cuidado. Para apps web, Google valida el client ID contra las URI de redirección pre-registradas. Si la URI de redirección no coincide exactamente, Google rechaza la solicitud.
Si solo haces unas pocas cosas bien, haz estas:
- Nunca incluyas un client secret en el code de la app. Los bundles web, los binarios móviles y los paquetes de Electron son inspeccionables por los usuarios.
- Registra las URI de redirección exactas. Casi no es suficiente. Google valida coincidencias estrictas para flujos web.
- Mantén los orígenes restringidos. No autorices dominios amplios solo para evitar la fricción de la configuración.
- Separa las credenciales por plataforma. No dejes que la conveniencia mezcle Android, iOS y web en una sola credencial.
Los equipos que evitan problemas tratan las credenciales de OAuth como cualquier otro secreto de producción. Mantienen los secretos de cliente web en el backend, los inyectan mediante la gestión de variables de entorno y auditan quién tiene acceso a la consola. Si estás limpiando tu pipeline de releases, esta guía sobre gestión de secrets en pipelines de CI/CD is worth applying to your auth setup too.
Solución de errores comunes de Client ID
La mayoría de los fallos de OAuth de Google se deben a un pequeño conjunto de errores de configuración. El texto del error no siempre es claro, pero el problema subyacente suele ser sencillo una vez que sabes dónde buscar.
redirect_uri_mismatch
Tu app está enviando una URI de redirección que no coincide exactamente con la registrada para ese cliente web. Revisa el esquema, el host, el path y cualquier diferencia al final.
invalid_client
Esto suele significar que la app está enviando el client ID incorrecto, el secret incorrecto para ese cliente, o que está mezclando credenciales entre plataformas.
origin_mismatch (Flujos de JavaScript)
El origen de la página no está listado en Orígenes de JavaScript autorizados para el cliente web.
Se requiere al menos un client ID cuando el inicio de sesión con Google está habilitado (Supabase, Firebase y dashboards similares)
El interruptor del proveedor está activado, pero ID de cliente web está vacío o se pegó de un proyecto incorrecto. Crea clientes OAuth en Google Cloud Console. Para Supabase, ingresa los client IDs de Web, Android e iOS como una lista separada por comas, con el de Web primero, cuando publiques esas plataformas. Configura los clientes nativos y guarda. Para Supabase con Capacitor, sigue la configuración de social login de Capacitor con Supabase.
DEVELOPER_ERROR, error 10, o el inicio de sesión funciona en debug pero falla en producción en Android
El cliente OAuth de Android falta o el nombre de paquete / SHA-1 no coincide con el keystore que firmó el APK que ejecutan los usuarios. Añade la huella del certificado de Play App Signing para las builds de la tienda. Confirma que tu plugin usa el ID de cliente web donde SDK espera un client ID de servidor, como se describe en la documentación de Capgo Social Login.
Google Sign-In funciona en web pero falla en móvil
Inspecciona primero el tipo de cliente. Una credencial web no puede reemplazar a un cliente Android o iOS para flujos nativos.
La pantalla de consentimiento se ve incorrecta
Verifica el nombre de la aplicación y la marca en la pantalla de consentimiento de OAuth en Google Cloud Console.
El orden práctico para depurar es simple: primero el tipo de cliente, luego la configuración de redirección, después los identificadores de plataforma y si un secreto va en el flujo.
FAQ
¿El ID de cliente Web y el ID de cliente Android deben estar en el mismo proyecto de Google Cloud?
Sí. Para Google Sign-In en Android, crea el cliente Android (nombre del paquete y SHA-1) y el cliente de aplicación Web en el mismo proyecto de Google Cloud. La app pasa el ID de cliente Web como ID de cliente del servidor, y Google verifica que el cliente Android pertenezca al mismo proyecto. Una discrepancia es una causa común de DEVELOPER_ERROR. El plugin de inicio de sesión social Capgo documentación muestra la configuración.
¿Qué es un Google client ID?
Es el identificador público de OAuth 2.0 que Google asigna cuando creas credenciales para tu app. Suele verse como 123456789012-abcdefg.apps.googleusercontent.com. Google lo utiliza cada vez que tu app inicia Sign in with Google o intercambia códigos de autorización por tokens.
¿Dónde encuentro mi Google client ID?
En Google Cloud Console, abre Google Auth Platform > Clients o APIs y servicios > Credenciales, luego abre tu cliente OAuth 2.0. El ID de cliente campo contiene la cadena completa para copiar.
¿Los clientes de Android e iOS incluyen un client secret?
Por lo general, no. Las apps instaladas son clientes OAuth públicos. Solo usa un client secret en un servidor que controles, normalmente con un Aplicación web Cliente OAuth.
¿Por qué mi backend dice que se requiere al menos un client id?
El inicio de sesión con Google está habilitado en el dashboard, pero no se ha guardado ningún client ID. Crea los clientes OAuth en Google Cloud Console y pega al menos el client ID de Web en la configuración del proveedor antes de habilitar la función para los usuarios.
¿Cómo solucionar el DEVELOPER_ERROR en Android?
Registra un cliente OAuth para Android con el nombre de paquete correcto y el SHA-1 de la clave de firma del dispositivo. Si distribuyes a través de Google Play, incluye el SHA-1 de Play App Signing. Asegúrate de que el client ID de Web coincida con lo que tu autenticación SDK espera.
¿Puedo reutilizar un solo client ID en todas las plataformas?
No. Crea clientes OAuth separados para Web, Android e iOS. Las apps de Capacitor suelen configurar los tres, incluso cuando los usuarios ven un solo producto.
Si tu equipo lanza Capacitor o apps de Electron, los errores de auth rara vez se quedan aislados. Suelen aparecer junto a la presión de las releases, la necesidad de rollbacks y los fixes específicos de cada entorno. Capgo ayuda a los equipos a publicar actualizaciones dirigidas a code y a los assets sin esperar la revisión de la tienda, lo que hace mucho más fácil corregir flujos de login, el manejo de callbacks y problemas de auth del lado del cliente cuando se cuelan en producción.
