Redirección OAuth apunta a localhost: reparar credenciales de Google/Microsoft

Cuando n8n muestra el error redirect_uri_mismatch al conectar una cuenta de Google o Microsoft, o cuando de repente acaba en http://localhost:5678/... tras hacer clic en «Sign in», casi siempre se debe a que n8n sigue construyendo la dirección de callback para el inicio de sesión OAuth a partir de los valores predeterminados localhost y el puerto 5678, en lugar de a partir de su dominio público real. Google o Microsoft comparan esta redirect URI enviada por el servidor n8n con la lista que usted ha guardado en la Google Cloud Console o en el registro de la aplicación de Microsoft, y rechazan el inicio de sesión en cuanto ambas no coinciden exactamente. La solución consiste en configurar correctamente las variables de entorno N8N_HOST, N8N_PROTOCOL y, sobre todo, WEBHOOK_URL o N8N_EDITOR_BASE_URL con el dominio público, e introducir después la redirect URI mostrada en el formulario de credenciales de n8n sin cambios en el proveedor de OAuth. Fecha: julio de 2026.

¿Por qué construye n8n la redirect URI precisamente a partir de localhost?

De forma predeterminada, n8n calcula automáticamente las direcciones del editor y de los webhooks a partir de tres variables, y sin una configuración propia, según la documentación de n8n sobre las variables de entorno de despliegue se aplican los valores predeterminados: http como N8N_PROTOCOL, localhost como N8N_HOST y 5678 como N8N_PORT. Mientras solo pruebe n8n localmente en su propio ordenador, esto no supone ningún problema, porque el navegador accede realmente a través de localhost. Pero en cuanto n8n se ejecuta en un servidor, en Docker o detrás de un reverse proxy, Google o Microsoft siguen accediendo al mismo valor localhost calculado automáticamente, porque n8n no sabe desde fuera bajo qué dominio es realmente accesible.

¿Cómo se configuran correctamente N8N_HOST, WEBHOOK_URL y N8N_EDITOR_BASE_URL?

La solución más fiable es establecer manualmente WEBHOOK_URL con el dominio público completo, ya que esta variable sobrescribe, según la documentación de n8n sobre la configuración de webhooks detrás de un reverse proxy toda la URL calculada automáticamente, y se muestra tanto en el editor como se registra en servicios externos.

• WEBHOOK_URL: establecer la dirección pública completa con una barra final, por ejemplo https://n8n.sudominio.es/, para que n8n use este dominio en lugar de localhost.
• N8N_HOST: establecer solo el dominio sin protocolo, por ejemplo n8n.sudominio.es, ya que n8n utiliza este valor junto con N8N_PROTOCOL y N8N_PORT para el cálculo automático de la URL.
• N8N_PROTOCOL: establecer en https en cuanto su servidor sea accesible mediante SSL, ya que el valor predeterminado según la documentación es http.
• N8N_EDITOR_BASE_URL: la URL pública bajo la cual los usuarios acceden al editor; según la documentación, también se usa para los correos electrónicos de n8n y como URL de redirección en el inicio de sesión SAML.
• N8N_PROXY_HOPS: establecer en 1 si hay un reverse proxy delante, para que n8n interprete correctamente las cabeceras de reenvío.

Tras establecer estas variables, hay que reiniciar el proceso o el contenedor de n8n, ya que n8n solo lee las variables de entorno al iniciarse.

¿Cómo se soluciona concretamente el error redirect_uri_mismatch?

El error se produce porque n8n envía un parámetro redirect_uri a Google o Microsoft al iniciar el flujo OAuth que no coincide con la redirect URI guardada en el proveedor, por lo que debe alinear manualmente ambos lados. Tras reiniciar n8n, abra de nuevo la credencial afectada y haga que se muestre la URL de redirección OAuth actual, que n8n construye bajo la ruta /rest/oauth2-credential/callback. Copie esta dirección sin cambios en la lista de redirect URIs autorizadas de su cliente OAuth de Google o de su registro de aplicación de Microsoft, y guárdela allí. Para las conexiones de Google, la documentación de n8n sobre problemas de Google Drive señala expresamente que N8N_EDITOR_BASE_URL y WEBHOOK_URL deberían usar dominios totalmente cualificados para evitar precisamente este redirect URI mismatch. Vuelva a conectar la credencial en n8n después para que se recupere el token actualizado.

¿Qué más se aplica cuando n8n se ejecuta detrás de un reverse proxy o en Docker?

Si n8n se ejecuta en contenedores detrás de nginx, Traefik o un Cloudflare Tunnel, a veces no basta con establecer las variables, porque el proxy debe reenviar a n8n las cabeceras originales, como X-Forwarded-Proto y X-Forwarded-Host, para que el servicio sepa internamente que la solicitud realmente llegó a través de https y del dominio público. Compruebe por ello, además de la configuración del proxy, si N8N_PROXY_HOPS está establecido, porque sin este valor n8n no confía en las cabeceras de reenvío del proxy y vuelve internamente a los valores predeterminados. Quien quiera operar una instancia de n8n en producción con varias conexiones OAuth, sin tener que reconfigurar las redirect URIs cada vez que se traslade el servidor, se beneficia de una configuración bien documentada; ese es uno de los puntos en los que NordFlux en la puesta en marcha de n8n presta apoyo, para que las automatizaciones con soberanía de datos alemana sigan funcionando de forma estable incluso después de una actualización.

Preguntas frecuentes sobre problemas de redirección OAuth en n8n

¿Tengo que reiniciar n8n después de establecer las variables?

Sí, es imprescindible reiniciar, porque n8n solo lee las variables de entorno al iniciarse el proceso o el contenedor. Sin reiniciar, la antigua redirect URI basada en localhost sigue activa, incluso si WEBHOOK_URL o N8N_HOST ya están configurados correctamente.

¿Basta con establecer solo WEBHOOK_URL?

En la mayoría de los casos sí, ya que, según la documentación de n8n, WEBHOOK_URL sobrescribe toda la URL calculada automáticamente y, con ello, también corrige la dirección de callback de OAuth. Además, solo necesita N8N_EDITOR_BASE_URL si los enlaces en los correos electrónicos enviados automáticamente o en las redirecciones SAML aún se muestran de forma incorrecta.

¿Por qué se produce redirect_uri_mismatch a veces también en n8n Cloud?

El error también puede producirse en n8n Cloud si la URL de redirección mostrada en el diálogo de credenciales ya no coincide exactamente con la dirección guardada en el proveedor, por ejemplo tras un cambio de dominio del workspace. En ese caso, ayuda copiar de nuevo la redirect URI mostrada actualmente y actualizarla en la Google Cloud Console o en el registro de aplicación de Microsoft.

¿Se aplica la misma solución también a las credenciales de Microsoft?

Sí, el principio es idéntico en las conexiones de Microsoft o Azure, ya que allí también se requiere una coincidencia exacta entre la redirect URI enviada por n8n y la reply URL guardada en el registro de la aplicación. Establezca por tanto las mismas variables N8N_HOST, N8N_PROTOCOL y WEBHOOK_URL, e introduzca la dirección mostrada en la credencial de n8n en la lista de reply URLs de su registro de aplicación de Azure.