Cómo solucionar el error 400: redirect_uri_mismatch de Google paso a paso

¿Alguna vez has intentado integrar el inicio de sesión con Google en tu proyecto y te has topado con el infame mensaje Error 400: redirect_uri_mismatch? No te preocupes, es más común de lo que parece y, aunque pueda parecer un auténtico rompecabezas al principio, tiene solución.

En este artículo te voy a explicar, con todo lujo de detalles, por qué ocurre este error, cuáles son los pasos precisos para corregirlo y cómo evitar que vuelva a suceder, tanto si trabajas en local, en producción o con sistemas híbridos como Docker, proxies reversos o frameworks específicos.

¿Qué significa el error 400: redirect_uri_mismatch?

El error 400: redirect_uri_mismatch aparece cuando el URI (dirección) de redirección que utiliza tu aplicación al solicitar autenticación a Google no coincide exactamente con el que has registrado en la Google Cloud Console. Esto es parte del sistema de seguridad de Google para prevenir accesos no autorizados y garantizar que solo las aplicaciones registradas puedan realizar operaciones sensibles con las cuentas de sus usuarios.

Este error puede manifestarse en toda clase de aplicaciones y plataformas: desde apps web tradicionales, pasando por frameworks de backend (Node.js, Python, PHP...), integraciones en sistemas como AWS Cognito, hasta plataformas de automatización como n8n o Make.com (antiguo Integromat). En todos los casos, hay un factor común: una diferencia mínima (una barra de más, un protocolo cambiado, un typo...) puede estropear el flujo de autenticación.

¿Por qué ocurre el error redirect_uri_mismatch?

Este error aparece porque Google comprueba que la URL de redirección que tu aplicación le envía sea exactamente igual (carácter por carácter) a la que tienes configurada como "Authorized redirect URI" en tu proyecto de Google Cloud Console.

Las causas pueden ser muy variadas, pero, según la documentación oficial de Google y las experiencias compartidas en foros y comunidades técnicas, las más habituales son las siguientes:

• Desajuste en el protocolo: Google distingue entre http:// y https://. Usar uno en desarrollo y otro en producción suele causar el fallo.
• Diferencias mínimas en la ruta o dominio: Un solo carácter extra, como una barra al final, un subdominio incorrecto o un caso (mayúsculas/minúsculas) diferente, desencadenan el error.
• No has registrado la URI en la consola de Google: Muchas veces falta añadir explícitamente la URL exacta (sin variables, sin omisiones) donde Google debe redirigir tras la autenticación.
• Configuraciones múltiples o clientes solapados: Si tienes varios proyectos, identidades o clientes OAuth2, puede que estés editando el equivocado o que tu aplicación esté usando unas credenciales distintas a las que piensas.
• Errores de configuración en proxies o contenedores: El uso de proxies reversos (NGINX, Apache, Traefik) o entornos Docker puede alterar la URL real que recibe el backend, provocando que Google la rechace.
• SSL mal configurado o ausente: Google suele bloquear redirecciones a URLs sin certificado SSL en producción.

¿En qué tipos de plataformas o contextos suele aparecer?

El error 400: redirect_uri_mismatch es transversal y puede amargar la vida tanto a desarrolladores web como a usuarios que configuran herramientas de terceros con Google. Algunos escenarios donde es especialmente habitual:

• Desarrollo local: Usar http://localhost: suele requerir añadir explícitamente la URI correspondiente en Google Cloud Console.
• Producción con dominio propio: Al pasar la app a producción, el dominio cambia. Si no se añade la nueva URI, el error aparece.
• Aplicaciones alojadas tras proxies reversos o balanceadores de carga: Si el tráfico pasa por NGINX o Apache, las rutas internas pueden diferir de las externas.
• Automatizaciones no code/low code: Plataformas como n8n o Make requieren añadir su URI específica que varía según configuración (docker, subdominios, etc).

Paso a paso: Cómo identificar y arreglar el error redirect_uri_mismatch

A continuación te detallo el proceso sistemático para detectar la causa y resolver el error, adaptando los consejos extraídos de Google, foros especializados y experiencias de desarrolladores reales.

1. Comprueba la URI de redirección utilizada por tu aplicación

El primer paso es identificar exactamente qué URI está enviando tu aplicación a Google durante la petición de autenticación. Esto puede variar según el framework, pero normalmente podrás ver la URI:

• En la configuración del login OAuth de tu app.
• En el panel de credenciales de la plataforma (por ejemplo, n8n muestra la URI exactamente en el apartado de configuración de credenciales/Google OAuth2).
• En los logs o mensajes de error (algunas librerías muestran la URI rechazada).

Ejemplo típico para n8n: https://n8n.tudominio.com/rest/oauth2-credential/callback

En desarrollo local podría ser: http://localhost:5678/rest/oauth2-credential/callback

En Node.js con Passport: Es posible que inicialmente tu configuración solo tenga una ruta relativa (/register/google/redirect), y esto provocará el error si Google espera una URI absoluta.

2. Revisa y sincroniza la configuración en Google Cloud Console

Ahora tienes que entrar en tu consola de Google de este modo:

1. Visita Google Cloud Console - APIs y servicios - Credenciales.
2. Localiza el proyecto y el ID de cliente OAuth2 (ojo con los clientes duplicados o de pruebas).
3. Edita el cliente y añade la URI de redirección exacta bajo "URIs de redirección autorizadas".
4. La URI debe coincidir carácter por carácter con la que usa tu app: mismo protocolo (http/https), dominio, subdominio, ruta y sin barras extra, espacios o parámetros dinámicos.
5. Guarda los cambios y espera unos segundos a que se propaguen.

Truco: Copia la URI directamente desde la app o la consola de logs y pégala tal cual en Google Cloud Console.

3. Repasa detalles habituales que suelen provocar el fallo

• Barras finales: La presencia o ausencia de una barra al final SÍ importa. https://tudominio.com/cb y https://tudominio.com/cb/ son diferentes.
• SSL: En producción, Google puede obligarte a usar https:// (no admite http:// salvo para localhost en desarrollo).
• Varios clientes/confusiones: Si tienes varias aplicaciones, ten cuidado con editar el cliente correcto y usar las credenciales adecuadas.
• Variables de entorno o cambios recientes: Si has modificado la URL base del entorno o el dominio, puede que tu app esté generando la URI con parámetros antiguos (VERIFICA CACHES y REINICIA la app).
• Reverse proxy/NGINX: Si usas un proxy, asegúrate de que esté reenviando todo correctamente a la ruta de callback y no esté alterando la URL o el protocolo (si tu proxy fuerza https pero tu backend está configurado en http, puede haber desajuste).

4. Consideraciones especiales según plataforma y framework

Integraciones en n8n

Al configurar Gmail u otros servicios con OAuth2 en n8n, la propia app te muestra el URI de redirección que tienes que registrar:

• Ve a Credenciales y selecciona Google OAuth2.
• Al editar, n8n ofrece un mensaje tipo: “Debes registrar la siguiente URL como URI de redirección autorizada…”.
• Cópiala exactamente y pégala en Google Cloud Console.
• Si usas Docker, asegúrate de que N8N_EDITOR_BASE_URL y WEBHOOK_TUNNEL_URL están bien configuradas, ya que esto afecta a la construcción de la URI.
• Tras modificar variables o la URL base, reinicia el contenedor para que los cambios tengan efecto.

Integraciones en Make.com (antiguo Integromat)

En plataformas de automatización, el callback puede variar según el servicio:

Ejemplo de URI: https://www.integromat.com/oauth/cb/google-analytics-4

Regístrala exactamente así en el apartado de URIs de Google, y si usas otros servicios, revisa en la documentación oficial cuál es la URI concreta.

Node.js con Passport.js

En Node.js (Passport o similares), la clave está en usar una URI absoluta en callbackURL:

• Incorrecto: callbackURL: "/register/google/redirect"
• Correcto: callbackURL: "https://tudominio.com/register/google/redirect"

Recuerda siempre actualizar Google Cloud Console cuando cambies la URL o el entorno.

AWS Cognito y Google OAuth2

Si integras Cognito (AWS) con Google, tendrás que añadir la URI específica de callback que uses en Cognito (Allowed Callback URLs) como Authorized Redirect URI en Google. No olvides que los errores pueden venir tanto por la configuración en Google como en Cognito.

5. Reinicia servicios tras hacer cambios

Tras cualquier cambio en la URI de redirección, variables de entorno o configuración de certificados/dominios, reinicia el servicio, contenedor o servidor web. Muchos frameworks o entornos dockerizados solo refrescan la configuración al iniciar.

6. Errores relacionados y cómo diferenciarlos

Google utiliza distintos mensajes “400” para identificar problemas concretos de autenticación con OAuth2. Aquí tienes una mini-guía para que puedas distinguirlos:

• 400 origin_mismatch: Error similar, pero relativo al origen del JavaScript (no a la URI de redirección), se corrige autorizando el dominio en la consola.
• 400 invalid_request / access_not_configured / admin_policy_enforced: Problemas distintos, causados por solicitudes mal formadas, políticas administrativas o accesos no configurados. Normalmente requieren intervención del administrador o modificaciones en los permisos OAuth.

Consejos y errores frecuentes

Basado en lo aprendido de la documentación de Google y numerosas consultas en foros y comunidades técnicas, aquí tienes algunos “gotchas”:

• La URI tiene que ser exacta: olvida las variables, los asteriscos o rutas dinámicas. Una sola diferencia, y fallará.
• No confíes solo en lo que ves en la barra del navegador: Si usas un proxy o balanceador de carga, la URL interna puede ser distinta.
• No uses http en producción: Google solo lo permite en localhost con fines de desarrollo.
• Si el error persiste tras los cambios, limpia caché del navegador, prueba en incógnito o espera unos minutos (a veces hay un pequeño delay en la propagación de permisos en Google).
• Comprueba siempre que editas el cliente y el proyecto correctos en la Google Cloud Console. Es frecuente tener duplicados y modificar uno que no afecta a la app real.
• Si usas varios dominios o entornos separados (producción, staging, desarrollo), añade explícitamente todas las URIs necesarias, cada una debe estar registrada.

Qué hacer si no tienes acceso a la configuración de Google Developers Console

En ocasiones, si tu aplicación es de terceros (no tuya), la única solución es contactar con el desarrollador y pedirle que registre correctamente tu URI de redirección.

Para identificar cómo contactar con el responsable:

1. Accede a la aplicación o servicio que te da el error.
2. Busca información de ayuda o soporte en su web (muchas veces el correo del desarrollador está en la pantalla de login de Google).
3. Explica exactamente la URI que estás usando y el mensaje de error.

Errores similares y cómo gestionarlos

• 401 invalid_client / deleted_client / disabled_client: Indican problemas en el lado del desarrollador (la app no está registrada correctamente o ha sido deshabilitada). Solo el propietario puede solucionarlo.
• 403 access_denied / policy_enforced / org_internal: Suelen deberse a políticas, restricciones de cuentas, limitación a ciertos dominios o programas de protección avanzada. Consulta a tu administrador o revisa los permisos de la cuenta de Google.
• 500 internal_failure: Se trata de errores internos transitorios. Normalmente basta esperar y reintentar.

Casos prácticos y experiencias reales

En distintas comunidades como StackOverflow, Google Cloud Community o foros de plataformas de automatización, decenas de desarrolladores han compartido sus problemas y la mayoría de casos se solucionan sincronizando de manera precisa las URIs. Algunos ejemplos útiles:

• Caso Node.js + Passport: Cambiar la configuración de la ruta de callback de relativa a absoluta (añadiendo https://tudominio.com delante) resolvió el error cuando Google no permitía HTTP en producción.
• n8n en Docker: Utilizar la URI mostrada en la configuración de credenciales, agregar las variables de entorno adecuadas y reiniciar el contenedor solucionó la autenticación con Gmail.
• AWS Cognito: Añadir tanto la URI usada en Cognito como el dominio propio (según corresponda) permitió superar el rechazo inicial de Google.

Herramientas útiles y recursos adicionales

Algunos enlaces que pueden ayudarte a resolver dudas más específicas:

• Guía oficial de errores de Google: Soporte de conexión de cuentas de Google
• Documentación de OAuth2 para n8n: Docs oficiales n8n - Google OAuth2
• Configurar OAuth2 en AWS Cognito: Amazon AWS Cognito - Social providers
• Make.com (Integromat): Ayuda OAuth2 Make.com

Cómo prevenir errores futuros con redirect_uri_mismatch

Para no volver a toparnos con este error más adelante, lo mejor es cuidar estos aspectos desde el principio:

• Diseña tu app con variables de entorno para las URIs (de esta manera cambiar de entorno es cuestión de cambiar la variable, no el código).
• Mantén actualizada tu documentación interna sobre qué URIs usa cada entorno y cliente.
• Automatiza el despliegue de URIs (si tu proyecto escala, evita errores humanos sincronizando automáticamente las URIs en Google Cloud Console con tus entornos de despliegue).
• Revisa regularmente los clientes y URIs autorizados en tus proyectos de Google Cloud para evitar confusiones por clientes obsoletos o duplicados.
• Haz pruebas de integración cada vez que cambias de subdominio, dominio o entorno base.

Este error puede ser frustrante, pero con un poco de paciencia y atención al detalle, es perfectamente solucionable. Registrando correctamente las URIs, revisando tu configuración y sabiendo cómo identificar el fallo concreto, tendrás tu integración con Google funcionando sin problemas tanto en desarrollo como en producción. Y recuerda, si te atascas, consulta la documentación oficial y las comunidades, porque seguro que alguien ya pasó por el mismo embrollo que tú.