Autenticación de webhooks en n8n: Header, Basic o JWT
Autenticación de webhooks en n8n paso a paso: añade Header, Basic o JWT a un nodo Webhook, prueba llamadas rechazadas y aceptadas con curl y elige un método.
Comprobado con las fuentes citadas el .
Objetivo y requisitos previos
Este tutorial muestra la autenticación de webhooks en n8n con un workflow de práctica. El objetivo es un nodo Webhook que rechace las llamadas sin credenciales válidas y acepte las que sí las tengan. Según la documentación de n8n, el nodo Webhook puede exigir a quien llama que se autentique con Basic auth, Header auth o JWT auth, o bien no exigir ninguna autenticación.
Necesitas un espacio de trabajo de n8n, un workflow con un disparador Webhook y curl o Postman para enviar solicitudes. Esta guía parte de la documentación y de fuentes de la comunidad que se nos facilitaron. No la hemos probado nosotros, así que confirma cada resultado en tu propia versión de n8n.
Sources: Webhook | Nodes | n8n Docs
Pasos para añadir autenticación a un webhook de n8n con una credencial Header auth
Usamos Header auth para la práctica porque requiere la menor configuración. Los pasos siguientes están ordenados; síguelos en secuencia. La secuencia de pruebas y el valor aleatorio largo son una práctica que sugerimos nosotros, no un procedimiento documentado de n8n.
- Añade un nodo Webhook y anota tanto la URL de prueba como la de producción.
- Crea una credencial Header auth: introduce un Name y un Value de cabecera. Usa un valor aleatorio largo.
- En el nodo Webhook, establece Authentication en Header auth y selecciona esa credencial.
- Llama a la URL de prueba con curl: una vez sin cabecera, otra con un valor incorrecto y otra con el valor correcto.
- Publica el workflow, repite las tres llamadas contra la URL de producción y revisa la pestaña Executions.
El nodo Webhook tiene URL de prueba y de producción por separado. La URL de prueba se registra cuando usas Listen for Test Event, o ejecutas el workflow mientras no está activo, y el editor muestra entonces los datos entrantes. La URL de producción se registra cuando publicas el workflow, y sus llamadas aparecen en la pestaña Executions en lugar de en el editor. Las versiones antiguas de n8n pueden decir activar en lugar de publicar.
En nuestra opinión, un valor de cabecera aleatorio y largo es la elección correcta para una primera construcción. Es fácil de crear, fácil de enviar desde curl y fácil de rotar más adelante. Como expectativa editorial, no como comportamiento documentado: una llamada sin cabecera o con un valor incorrecto debería rechazarse y no iniciar el workflow. El valor correcto debería iniciarlo, y se vería en el editor con la URL de prueba o en Executions con la URL de producción.
Sources: Webhook | Nodes | n8n Docs, Webhook credentials | Nodes | n8n Docs
Uso de Basic auth o de la autenticación de webhooks en n8n con JWT
Basic auth usa una credencial con Username y Password. La documentación de n8n dice que JWT auth usa la credencial JWT, cuyo tipo de clave es una Passphrase o una clave PEM. La documentación de credenciales enumera las opciones de passphrase (secreto HMAC) o par de claves PEM, y algoritmos de las familias HS, RS, ES y PS, además de none. La documentación no ofrece consejos de seguridad sobre la opción none, así que infórmate antes de elegirla.
- Crea la credencial: Username y Password para Basic auth, o una credencial JWT con una Passphrase o clave PEM y un algoritmo.
- En el nodo Webhook, establece Authentication en Basic auth o JWT auth.
- Selecciona la credencial que creaste en el campo de credencial del nodo.
- Para JWT, envía el token en una cabecera Authorization con el prefijo Bearer, como describen los miembros de la comunidad.
- Ejecuta las mismas llamadas de prueba que en los pasos de Header auth.
Un miembro de la comunidad escribió en abril de 2025 que un JWT se envía como cabecera Authorization con el prefijo Bearer, y que el disparador Webhook expone entonces el contenido del token en una propiedad jwtPayload. Es un testimonio de la comunidad, no un comportamiento documentado. Un tutorial de Medium de septiembre de 2025 trata un token de Auth0: una credencial de clave PEM con la clave pública y un algoritmo como RS256.
Ten cuidado con los claims. El fundador de una consultora, escribiendo en el blog de un proveedor en septiembre de 2025, plantea lo siguiente. La documentación que tenemos no dice qué claims cubre la comprobación integrada, así que prueba con un token caducado.
Basic auth tiene su propia salvedad de versión. Una incidencia de GitHub contra n8n 2.9.0 informó de un 403 en lugar de un 401 con credenciales Basic auth incorrectas, y un mantenedor dijo después que se corrigió en n8n 2.30.0. Los códigos de estado de las llamadas rechazadas pueden variar según la versión.
Sources: Webhook credentials | Nodes | n8n Docs, JWT credentials | Nodes | n8n Docs, Using JWTs (JSON Web Tokens) for Authenticated Webhooks - Tips & Tricks - n8n Community, Authentication with n8n is Easier Than You Think | by Sean Spaniel | Medium, n8n Webhooks: A Beginner’s Guide (with Security Built-In), Webhook Basic Auth Returns 403 Instead of 401 for Invalid Credentials · Issue #26365 · n8n-io/n8n · GitHub
Elegir un método para llamadas en producción
La documentación facilitada no ofrece una clasificación de seguridad de los tres métodos de autenticación de webhooks en n8n. La comparación siguiente es un consejo editorial, que en parte se hace eco de un blog de proveedor de 2026 de n8nlogic, el cual prefiere Header auth para llamadas de máquina a máquina y JWT cuando quien llama ya emite tokens, y considera Basic auth la más débil. Ese blog promociona sus propios servicios, así que tómalo como una opinión.
| Método | Campos de la credencial | Uso sugerido |
|---|---|---|
| Header auth | Name y Value de la cabecera | Opción por defecto para llamadas entre sistemas |
| JWT | Passphrase o clave PEM | Llamadas de quienes ya emiten tokens firmados |
| Basic auth | Username y Password | Solo cuando quien llama no ofrece nada más |
Descartaríamos Basic auth salvo que quien llama no admita nada más.
Sources: Webhook credentials | Nodes | n8n Docs, n8n Webhook Node: Triggers, Auth & Responding (2026) | n8nlogic
Refuerzo, rotación de secretos y solución de problemas
Junto con la autenticación de webhooks en n8n, la opción IP(s) Allowlist del nodo Webhook devuelve un 403 a quienes llaman desde fuera de la lista, y una lista vacía permite todas las direcciones. Limita quién puede intentarlo, así que úsala además de la autenticación, no en su lugar.
Una agencia de un proveedor aconseja una credencial distinta por cada sistema que llama, de modo que rotar un secreto no rompa a los demás. También advierte de que dejar la autenticación en none permite que cualquiera con la URL inicie el workflow. Un autor de la comunidad añade que las caducidades de token muy largas dificultan invalidar un token filtrado. Para el almacenamiento, n8n documenta almacenes de secretos externos en n8n Cloud Enterprise y en Enterprise autoalojado, con proveedores como HashiCorp Vault y AWS Secrets Manager; la página no dice si las credenciales de webhook pueden usarlos.
Si una llamada no es rechazada, comprueba que Authentication del nodo no siga en none y que llamaste al modo de URL correcto. Si todas las llamadas fallan, compara exactamente el Name y el Value de la cabecera. No compartas la URL hasta que las llamadas rechazadas fallen como se espera.
Sources: Webhook | Nodes | n8n Docs, Using JWTs (JSON Web Tokens) for Authenticated Webhooks - Tips & Tricks - n8n Community, Configure the n8n Webhook Node: 15 Parameters Explained | Hack'celeration, Use external secret stores | Administer | n8n Docs
