Inicio de sesión SSO en n8n: diagnostica un fallo paso a paso
Un ejercicio de SSO en n8n: pasos para separar la configuración de n8n, el proveedor de identidad y la red cuando falla un login SAML.
Comprobado con las fuentes citadas el .
Ejercicio editorial: tarea y alcance
Este es un ejercicio editorial, no un script de diagnóstico validado: una forma estructurada de practicar cómo abordar un fallo de inicio de sesión SSO en n8n, no una herramienta que hayamos probado en tu instancia. Imagina este escenario: tu equipo activó SAML SSO en n8n y ahora el inicio de sesión falla con un error en lugar de devolver el control a tu aplicación. Tu tarea es determinar, paso a paso, si el fallo está dentro de la propia configuración de n8n, dentro de la configuración del proveedor de identidad, o en algún punto de la ruta de red que conecta a ambos, antes de escalar el ticket a tu equipo de identidad o de asumir que n8n está roto.
Este ejercicio se centra estrictamente en fallos de inicio de sesión SAML una vez que el SSO ya está configurado. No cubre si conviene adoptar SSO en primer lugar ni en qué se diferencian los fallos de OIDC, ya que esa base pertenece a otro lugar. Trata cada comprobación sugerida a continuación como un punto de partida que debes adaptar a tu propio entorno, no como una lista de verificación que n8n publique de principio a fin.
Requisitos previos y los datos de partida
Antes de empezar, confirma que dispones de lo que este ejercicio asume. n8n documenta el SSO SAML como una función disponible en los planes Business y Enterprise, y configurarlo requiere iniciar sesión como propietario o administrador de la instancia. Reúne lo siguiente antes de comenzar:
Para este ejercicio, asume que dispones de tres cosas: un intento de inicio de sesión fallido con el error que n8n muestre en pantalla, acceso a la propia pantalla de configuración de SSO de n8n, y acceso de administrador al proveedor de identidad que use tu organización, como Okta o Microsoft Entra ID. En nuestra opinión, vale la pena gestionar ese acceso al proveedor de identidad antes de empezar, aunque suponga un paso de aprobación extra, porque sin él solo puedes ver la mitad de la conversación que corresponde a n8n.
Sources: Set up SAML | Administer | n8n Docs, Configure SSO | Deploy | n8n Docs
Paso a paso: diagnosticar un fallo de inicio de sesión SSO en n8n
Con los requisitos previos listos, recorre las siguientes cinco comprobaciones en orden, resistiendo la tentación de saltar directamente al proveedor de identidad cuando falla un inicio de sesión SSO de n8n. Cada comprobación añade una evidencia independiente sobre dónde está realmente el fallo.
Empieza dentro de n8n antes que nada. La propia documentación de configuración SAML de n8n indica que n8n no admite el binding POST, así que si tu proveedor de identidad todavía está configurado para enviar una respuesta POST, esa discrepancia es una causa de fallo documentada y del lado de n8n, no un defecto del proveedor de identidad. Si el SSO se configuró mediante variables de entorno, disponibles desde la versión 2.18.0 de n8n, recuerda que n8n vuelve a aplicar esas variables en cada reinicio y bloquea los controles de la interfaz correspondientes, así que un ajuste que parezca incorrecto en pantalla puede simplemente estar controlado por el entorno.
A continuación, ejecuta la propia acción Test settings de n8n, en Settings > SSO, que n8n describe como una forma de comprobar tu configuración SAML antes de activarla. La propia página de solución de problemas de n8n mantiene este paso deliberadamente breve, limitado a tres comprobaciones, ya que la documentación de n8n no va más allá de esta lista:
Si Test settings pasa pero el inicio de sesión real sigue fallando, deja de confiar únicamente en el error que muestra n8n en pantalla y captura lo que realmente circuló por la red. La documentación de Okta recomienda un complemento de navegador como SAML-tracer precisamente para esto, tanto para flujos iniciados por el proveedor de identidad como por el proveedor de servicios. Una guía general de depuración SAML de WorkOS señala algo similar: reproducir el intento mientras se registra el tráfico muestra campos como audience, recipient, timestamp y signature que un mensaje de error breve no te mostrará.
La propia documentación de soporte de Okta, actualizada por última vez en 2026, trata un par de solicitud/respuesta capturado con éxito como confirmación de que tu lado del intercambio funciona correctamente con Okta, y enumera las categorías de fallo que una traza decodificada suele revelar: discrepancias de URL ACS, discrepancias de audience, errores de certificado y problemas de mapeo de atributos. Creemos que este paso de decodificar la traza merece los minutos extra aunque parezca más lento que leer el texto de error de n8n, porque es la única comprobación que muestra lo que el proveedor de identidad realmente envió, y no lo que n8n informa haber recibido.
Antes de pasar a los registros propios del proveedor de identidad y a la salida de depuración de n8n en las dos comprobaciones siguientes, ayuda comparar qué puede y qué no puede confirmar la evidencia reunida hasta ahora:
| Fuente de evidencia | Qué confirma | Qué no te puede decir |
|---|---|---|
| El resultado de Test settings de n8n | Si los campos introducidos en la propia pantalla de SSO de n8n parecen correctos | Si el proveedor de identidad realmente emitió una aserción válida |
| Una traza SAML decodificada | Los campos exactos que envió el proveedor de identidad y cómo respondió n8n | Por qué la propia lógica de n8n rechazó una aserción en apariencia válida, si eso ocurrió |
| El registro de inicio de sesión del proveedor de identidad | Si el proveedor de identidad emitió una aserción para ese intento | Qué le ocurrió a esa aserción una vez que llegó a n8n |
| El registro de servidor de n8n en nivel debug | Un registro con marca de tiempo, del lado de n8n, del mismo intento de inicio de sesión | El contenido de la aserción que realmente envió el proveedor de identidad |
Trata los propios registros del proveedor de identidad como una segunda fuente, independiente. La documentación de Microsoft Entra ID describe cómo filtrar los registros de inicio de sesión por aplicación y estado de fallo para obtener un ID de correlación, un código de error y un motivo de fallo, y documenta un código específico, AADSTS750054, que significa que la solicitud o respuesta SAML faltaba en la cadena de consulta para el binding de redirección, lo que apunta a un problema de binding o configuración en lugar de una caída del servicio.
Para integraciones con Okta, la propia guía de configuración de n8n señala que una conexión que funciona correctamente termina con n8n mostrando un mensaje de éxito que enumera los atributos que devolvió Okta, lo que te da una base de referencia concreta que funciona. Si un rol o reclamación parece incorrecto solo después de un inicio de sesión exitoso, la guía de Azure AD de n8n trata eso como un síntoma independiente, que apunta a la pertenencia a grupos y al orden de las condiciones, y no a la autenticación en sí.
Por último, activa el nivel de registro debug de n8n, que la propia documentación de n8n describe como la salida más detallada disponible, pensada para ayudar a depurar problemas como este, durante la duración de tu prueba, de modo que tengas un registro con marca de tiempo del lado de n8n. Un caso reportado por la comunidad en el propio foro de n8n, de julio de 2025, muestra por qué esto importa: un usuario Enterprise autoalojado vio un error 'Could not parse SAML response' con el código ERR_REDIRECT_FLOW_BAD_ARGS aunque la URL de redirección, el entity ID y los metadatos coincidían con el proveedor de identidad, y rastreó la causa real hasta un proxy de autenticación que bloqueaba el endpoint SAML frente a n8n.
Sources: Set up SAML | Administer | n8n Docs, SSO | Deploy | n8n Docs, Troubleshoot SAML | Administer | n8n Docs, Okta SAML Login Failing: "Could not parse SAML response" - Questions - n8n Community, Diagnosing SAML assertion failures: A step-by-step debugging guide — WorkOS, Test SAML app implementation with SAML-tracer | Okta Developer, How to Troubleshoot SAML Flows Using SAML Tracer in Okta | Okta Support, Set up logging | Deploy | n8n Docs, How to troubleshoot sign-in errors - Microsoft Entra ID | Microsoft Learn, Error AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding. | Microsoft Learn, Set up Azure AD SAML | Administer | n8n Docs, Set up Okta Workforce Identity SAML | Administer | n8n Docs
Restricciones y criterios de finalización
Ten en cuenta algunas restricciones al ejecutar este ejercicio. Evita cambiar la configuración en vivo de tu proveedor de identidad sin una ventana de cambios, ya que esa configuración es infraestructura compartida más allá de tu instancia de n8n. Cuando sea posible, prueba contra un usuario de prueba dedicado o una aplicación de staging en lugar de la integración SSO principal de tu organización, y anota cada comprobación y su resultado sobre la marcha, ya que el objetivo es comparar evidencia entre capas y no arreglar las cosas por ensayo y error.
Puedes considerar este ejercicio completo cuando puedas explicar por qué falló un intento concreto de inicio de sesión SSO en n8n, señalando la configuración de n8n, la configuración del proveedor de identidad o la ruta de red entre ambos, respaldado por evidencia y no por una suposición. Usa esta lista de verificación para confirmar que has llegado a ese punto:
Sources: Set up SAML | Administer | n8n Docs, SSO | Deploy | n8n Docs, Diagnosing SAML assertion failures: A step-by-step debugging guide — WorkOS, Test SAML app implementation with SAML-tracer | Okta Developer, How to troubleshoot sign-in errors - Microsoft Entra ID | Microsoft Learn
Reflexión: una ruta de diagnóstico sugerida y errores que imitan un problema del IdP
Las comprobaciones anteriores cubren la configuración de n8n, el proveedor de identidad y la conexión entre ambos, pero merece la pena nombrar directamente algunos patrones de fallo porque a primera vista parecen un problema del proveedor de identidad.
Trataríamos esa solución del proxy de autenticación como un ejemplo útil de causa a nivel de red, no como prueba de lo que ese código de error significa en general, ya que proviene de un único caso autoreportado y no de la propia documentación de n8n.
La propia página de solución de problemas de n8n para SAML se mantiene deliberadamente breve, limitada a comprobar que la aplicación del proveedor de identidad admite SAML, la exactitud de la URL de redirección y el entity ID, y el formato de los metadatos, por lo que este ejercicio se apoya en herramientas del proveedor de identidad y en ese único reporte de la comunidad para completar el resto del panorama. Úsalo como una estructura de partida para tu propia investigación, no como un instrumento validado o exhaustivo.
Sources: Set up SAML | Administer | n8n Docs, SSO | Deploy | n8n Docs, Troubleshoot SAML | Administer | n8n Docs, Okta SAML Login Failing: "Could not parse SAML response" - Questions - n8n Community, Set up Azure AD SAML | Administer | n8n Docs
