Probablemente esté aquí porque Google Sign-In debería haber sido una integración rápida, y en su lugar se encuentra frente a una pantalla de credenciales preguntándose por qué un tipo de aplicación le da un secreto de cliente y otro no. Esa confusión es normal, especialmente si está construyendo con Capacitor, Ionic, Electron o una pila web y nativa mixta.
La parte que más guías omiten es la que rompe las implementaciones reales: Ids de cliente de Google son específicos de la plataformay no tipos de aplicaciones no web no obtienen un secreto de cliente por diseño. Si crea la credencial equivocada para forzar un secreto en el flujo, usualmente acaba con un conjunto de OAuth roto que es más difícil de depurar de lo que debería ser.
Índice de Contenido
- Conectando su Aplicación al Ecosistema de Google
- ¿Qué es un Id de Cliente de Google?
- Cómo crear y visualizar su ID de cliente
- Configuraciones de ID de cliente específicas de plataforma
- Seguridad de sus credenciales de Google API
- Resolución de Errores Comunes de Identificador de Cliente
Conectar su aplicación al ecosistema de Google
Muchas equipos se enfrentan a este problema al mismo tiempo. Necesitan Iniciar sesión con Googleo desean acceso aprobado por el usuario a algo como Drive o Calendario, y una clave API deja de ser suficiente.
, o quieren acceso aprobado por el usuario a algo como Drive o Calendario, y un __CAPGO_KEEP_0__ clave de repente deja de ser suficiente. su aplicación, not just the API being called. The credential that does that is the ID de cliente de Google.
If you’re working in a cross-platform codebase, the confusion gets worse fast. You might have a web frontend, an Android shell, an iOS app, and maybe an Electron build for desktop. They may share product branding and backend logic, but they should not all share one OAuth identity.
Una configuración OAuth práctica suele reducirse a unas pocas preguntas de implementación.
- ¿Qué tipo de aplicación deberías crear
- ¿Necesita un secreto de cliente
- ¿Cuáles URIs de redireccionamiento o orígenes deben coincidir exactamente
- ¿Cómo conectar flujos móviles y web sin mezclar credenciales
- ¿Por qué un flujo que funciona en el navegador falla dentro de un wrapper nativo
Regla práctica: Si su aplicación solicita permiso del usuario o inicio de sesión, comience pensando en tipos de clientes OAuth, no API claves
Esta distinción ahorra tiempo temprano. También evita el error común de crear un flujo de inicio de sesión móvil alrededor de una credencial web solo porque el consola mostró más campos. Si está implementando esto en una Capacitor aplicación, esta guía sobre OAuth2 en Capacitor aplicaciones Es una compañera útil para el flujo de la aplicación.
¿Qué es un ID de cliente de Google
Un ID de cliente OAuth 2.0 de Google 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 para una aplicación cuando solicita tokens de acceso desde los puntos de conexión de autenticación de Google, y destaca que es distinto de las API porque se utiliza en los flujos de OAuth para verificar la identidad de la aplicación durante el intercambio de tokens, como se explica en Documentación del cliente OAuth de Google Cloud.
El modelo mental simple
Pensa en el ID de cliente de Google problemas en tu aplicación nombre de usuario público.
It tells Google, “this request is coming from this registered application.” That matters during sign-in, consent, token exchange, and any flow where your app asks to act on behalf of a user. The client ID is meant to be referenced by both your app and Google’s auth servers.
¿Qué confunde a las personas es que este credencial se encuentra junto a dos otros conceptos que no son intercambiables.
ID del cliente ID de cliente de Google
API clave identifica un proyecto para ciertas llamadas a API que no involucran la autorización de usuario delegada.
Cliente secreto es el contraparte confidencial utilizado solo en flujos y tipos de aplicación que pueden mantener secretos de manera segura.
Muchas integraciones rotas comienzan cuando alguien trata a estas como variaciones del mismo cosa. No lo son.
¿Dónde se ajusta el cliente ID de Google en la práctica?
Si necesitas Iniciar sesión con Google o Un solo toque, the client ID is the value your frontend uses to initiate the authentication handshake. Google’s documentation also notes that the app must be registered in a dedicated Cloud Console project before the credential can be generated, and that web apps require configured authorized JavaScript origins or redirect URIs with the full scheme and hostname.
That’s why the setup feels stricter than generating a simple key. Google isn’t just enabling access. It’s binding the auth request to a known app identity.
Para equipos que construyen aplicaciones híbridas, el modelo mental más seguro es este:
- Utilice el ID de cliente para identificar la aplicación
- Utilice la pantalla de consentimiento para representar la aplicación al usuario
- Utilice el tipo de aplicación correcto para determinar si un secreto pertenece al flujo
Si desea una guía más amplia sobre cómo la identidad de la aplicación y el acceso delegado se relacionan entre sí esta guía sobre la autorización de la aplicación es una buena actualización.
Cómo crear y ver su identificador de cliente
El camino del consola ha cambiado lo suficiente como para que los desarrolladores piensen que están en el lugar equivocado. Normalmente no lo están. Google expone actualmente dos rutas de navegación para estas credenciales: la más nueva Google Auth Platform > Clientes y la más antigua APIs & Services > Credenciales ruta, tal como se describe en documentación de configuración de Google.
Comienza en el área de la consola correcta
Abra la consola de Google Cloud y seleccione o cree el proyecto que será dueño de la configuración de autenticación. No dispersar la autenticación en proyectos aleatorios. Esto hace que la auditoría y el soporte sean dolorosos más tarde.
Desde allí, vaya a cualquiera de estos lugares:
- Plataforma de autenticación de Google > Clientes
- APIs y Servicios > Credenciales
Si su equipo ve diferentes etiquetas de navegación, eso es esperado. Google ha estado separando la configuración de identidad de la superficie de credenciales restante del API.
Crear la credencial sin encerrarse a sí mismo
Cuando cree un nuevo cliente OAuth, la decisión más grande es el tipo de aplicaciónGoogle te pide que elijas un tipo específico como Web, Android, iOSo Desktop. Esa elección no es estética. Define cómo se identifica la aplicación y qué configuración de apoyo es necesaria.
Para una aplicación web, espera ingresar:
- Orígenes de JavaScript autorizados
- URIs de redireccionamiento autorizadas
Esos valores deben ser exactos. Para un credencial de web, Google espera el esquema completo y el nombre de host, como https://www.example.com, en lugar de un concepto de dominio suelto.
Para las plataformas móviles, la forma es diferente. La inscripción de Android requiere la verificación de identidad y propiedad a nivel de paquete, mientras que iOS utiliza sus propios identificadores de plataforma. Si está combinando la autenticación de Google con otra capa de autenticación, este Capacitor configuración de inicio de sesión social con Supabase es un ejemplo útil de cómo estos piezas suelen encajar entre sí.
Esta guía paso a paso es una buena referencia visual si desea comparar la interfaz mientras navega:
Dónde encontrarlo más tarde
Después de la creación, el ID del cliente aparece en la lista de credenciales del proyecto. Ese mismo espacio de proyecto es donde las equipos habilitan las API y visualizan cómo la identidad OAuth se conecta a la pantalla de consentimiento. El nombre de la aplicación registrada es lo que los usuarios ven durante la solicitud de permiso, lo que es una razón por la que nombrar la aplicación con precisión importa.
Google mantiene estos credenciales manejables con el tiempo. Puede regresar a la consola para copiar el ID del cliente, revisar las configuraciones y, donde sea aplicable, gestionar el secreto de cliente asociado con esa credencial.
La pantalla de consentimiento no es decoración. Es parte de la frontera de confianza. Los usuarios ven el nombre de su aplicación allí, no el apodo de proyecto interno.
Configuraciones de ID de cliente específicas de plataforma
La forma más rápida de romper una configuración de inicio de sesión de Google es asumir que un ID de cliente puede cubrir todas las plataformas. No puede. Para aplicaciones multiplataforma, cada plataforma debe registrar su propio ID de cliente OAuth 2.0 distinto, y la configuración de Android requiere específicamente la huella SHA1 para verificar la propiedad, como se menciona en esta referencia de configuración de plataforma.
Why one app needs multiple client IDs
Su producto puede ser una aplicación única para el usuario, pero es múltiples clientes OAuth para Google.
A aplicación web, una compilación de Android, una iOS buildy una desktop app La separación es una buena higiene de seguridad. Si la configuración de credenciales de una plataforma se ve comprometida o mal configurada, las otras no se ven automáticamente expuestas.
Esa separación es buena higiene de seguridad. Si la configuración de credenciales de una plataforma se ve comprometida o mal configurada, las demás no se exponen automáticamente.
Aquí está la práctica división a seguir:
- Web Utiliza un ID de cliente web y una coincidencia estricta de origen y URI de redireccionamiento.
- Android usa un identificador de cliente Android vinculado a la identidad del paquete y la huella SHA1.
- iOS uses an iOS client ID tied to the app’s bundle identity.
- Desktop o Electron A menudo utiliza un patrón OAuth instalado o de escritorio en lugar de un flujo de navegador basado en secretos.
Tipos de identificador de cliente de Google comparados
| Tipo de aplicación | Identificador principal | Proporciona Secreto del Cliente? | Uso de Caso |
|---|---|---|---|
| Web | Orígenes de JavaScript autorizados y URIs de redireccionamiento | Suele ser sí | Aplicaciones de navegador y OAuth asistido por backend |
| Android | Identidad del paquete más huella SHA1 | A menudo no | Iniciar sesión en Android nativo |
| iOS | Identidad del paquete de la aplicación | A menudo no | Iniciar sesión nativa de iPhone y iPad |
| Escritorio | Identidad de la aplicación instalada | A menudo no | Aplicaciones de escritorio, incluyendo flujos nativos estilo Electron |
El paradoja del secreto del cliente para móviles y escritorios
Esto es lo que muchos tutoriales hacen mal.
Los desarrolladores de móviles y escritorios esperan a menudo que cada cliente OAuth tenga tanto un ID del cliente como un secreto del cliente. Luego crean un Aplicación Web credencial porque esa es la única forma de ver un secreto en la consola. El flujo parece más completo, así que siguen adelante. Más tarde, la autenticación falla de maneras confusas.
According to Esta explicación de la incompatibilidad de credenciales móviles, los tipos de aplicaciones no web como Android, iOS y aplicaciones instaladas suelen recibir un ID de cliente pero no un secreto de cliente intencionalmente, porque Google no quiere que un secreto confidencial esté integrado en el software del lado del cliente donde los usuarios pueden extraerlo.
Esa elección de diseño es correcta. Una aplicación móvil o un paquete de Electron no es un almacén seguro de secretos.
Lo que funciona: Flujos de autenticación OAuth nativos o diseñados para clientes públicos.
Lo que no funciona: Crear una credencial web para una aplicación móvil solo para obligar a un secreto en la implementación.
Para los equipos Capacitor, esto suele aparecer en uno de dos malos patrones:
- La aplicación lanza un flujo basado en navegador utilizando un cliente web y luego intenta comportarse como un servidor confidencial.
- La aplicación envía un segredo de cliente desde code empaquetado, lo que socava el propósito de tener un secreto.
La mejor aproximación es tratar a las aplicaciones móviles y de escritorio como clientes públicos. En OAuth moderno, eso generalmente significa utilizar un flujo que no depende de un secreto escondido dentro del cliente. Si su back-end está involucrado, mantenga las operaciones confidenciales en el back-end y mantenga la aplicación nativa limitada a lo que un cliente público debería hacer.
Otro punto sutil importa para el inicio de sesión de Android respaldado por Firebase. En ese escenario, el tipo de cliente de aplicación web se utiliza como el ID de cliente de OAuth del servidor de back-end, mientras que la aplicación de Android mantiene su propia identidad específica de plataforma. Esa división confunde a los equipos porque ven tanto un credencial de web como un credencial móvil en el mismo proyecto y asumen que uno reemplaza al otro. No es así. Sirven roles diferentes.
Si recuerdas una regla, usa esta: seleccione el tipo de cliente que coincida con donde se ejecuta el code, no la forma de credenciales que desearías tener.
Seguridad de credenciales de Google API
La mayoría de los incidentes de OAuth no se deben a ataques complejos. Los equipos divulgaban credenciales, ampliaron demasiado los ajustes de redirección o pusieron secretos en lugares donde nunca estaban seguros.
La guía de OAuth de Google enfatiza que los IDs de cliente y secretos deben tratarse como datos privados, y para aplicaciones web, el ID de cliente se aplica contra URIs de redirección pre-registradas. Si la URI de redirección no coincide estrictamente, Google rechaza la solicitud. Esa vinculación de origen es parte de la protección contra la interceptación de tokens, como se describe en Guía de registro de clientes de OAuth.com.
Qué cerrar inmediatamente
Si solo haces un par de cosas bien, haz estas:
- No envíes un secreto de cliente en la aplicación code. Paquetes de bundles web, binarios móviles y paquetes de Electron son inspeccionables por los usuarios.
- Registra URIs de redirección exactas. Lo suficiente no es suficiente. Google valida coincidencias estrictas para flujos web.
- Conserva los orígenes ajustados. No autorice dominios amplios solo para superar la fricción de configuración.
- Separe las credenciales de plataforma. No dejen que la comodidad combine Android, iOS y web en una sola credencial.
Un detalle operativo es fácil de pasar por alto. Google permite a los equipos generar nuevos secretos para un ID de cliente existente y deshabilitar los antiguos. Eso importa cuando un secreto se expone o cuando se está ajustando el proceso de despliegue.
¿Qué equipos seguros realmente hacen
Los equipos que evitan problemas tratan las credenciales de OAuth como cualquier otro secreto de producción.
Guardan los secretos de clientes web en el backend, los inyectan a través de la gestión de entornos y auditan a quién tiene acceso a la consola. Si estás limpiando tu pipeline de lanzamiento, esta guía sobre gestión de secretos en pipelines de CI/CD es aplicable también a tu configuración de autenticación.
También revisan la metadata, no solo las claves. La pantalla de consentimiento de OAuth está vinculada a la identidad del cliente que los usuarios ven. Si el nombre de la aplicación es vago o engañoso, los usuarios son más propensos a no confiar en la solicitud o aprobar la aplicación equivocada.
La seguridad no solo se trata de ocultar un secreto. También se trata de asegurarse de que la identidad del app, los objetivos de redireccionamiento y la pantalla de aprobación se alineen cada vez.
Diagnosticar Errores Comunes de Identificador de Cliente
La mayoría de los errores de OAuth de Google provienen de un pequeño conjunto de errores de configuración. El texto de error no siempre es amable, pero el problema subyacente suele ser claro una vez que se sabe dónde buscar.
The fixes that solve most failures
redirect_uri_mismatch
Su app está enviando una URI de redireccionamiento que no coincide exactamente con lo registrado para ese cliente web. Verifique el esquema, el host, la ruta y cualquier diferencia de cola. Para OAuth web, el ajuste exacto es parte del modelo de seguridad.
invalid_client
Esto suele significar que la app está enviando el ID de cliente incorrecto, la clave secreta incorrecta para ese cliente o mezclando credenciales entre plataformas. Un ejemplo común es un flujo de Android o iOS que accidentalmente utiliza la credencial web en el lugar incorrecto.
invalid_request
Esto es amplio, pero en aplicaciones de varias plataformas a menudo apunta a parámetros de autenticación malformados o un flujo que no se ajusta al tipo de cliente. Verifique si la app está tratando de incluir una clave secreta donde no debe, o si el flujo de OAuth seleccionado espera un tipo de cliente diferente.
Google Sign-In funciona en la web pero falla en móvil
La primera cosa a inspeccionar es el tipo de cliente. La fuente más común de error para los desarrolladores de móvil es crear un ID de cliente de aplicación web solo para obtener una clave secreta, cuando deberían estar utilizando tipos de Android o iOS que a menudo omiten la clave secreta intencionalmente, como se explica en desglose de la incompatibilidad del secreto del clienteSi su implementación incluye trabajo de ciclo de tokens después de la autenticación, la guía de revocación también es útil.
Iniciar sesión en Android falla después de la creación de credenciales
Verifique la huella SHA1 adjunta al cliente de Android. Si la identidad de firma no coincide con lo que Google espera, la aplicación no demostrará la propiedad correctamente.
La pantalla de consentimiento parece incorrecta
Verifique el nombre de la aplicación y la marca adjunta a la configuración de OAuth en la consola. Los usuarios autorizan lo que ven allí, por lo que los metadatos incorrectos crean tanto problemas de confianza como ruido de soporte.
El orden de depuración práctico es simple: Verificar el tipo de cliente primero, luego ajustes de redirección, luego identificadores de plataforma, luego si un secreto pertenece al flujo en absoluto..
Si su equipo envía Capacitor o aplicaciones Electron, los errores de autenticación rara vez permanecen aislados. Suele surgir junto con la presión de liberación, las necesidades de devolución y las correcciones específicas del entorno. Capgo helps teams ship targeted updates to app code and assets without waiting on store review, which makes it much easier to correct login flows, callback handling, and client-side auth issues when they slip into production.
