Gestión de Webhooks
Los webhooks permiten a Auris notificar a tus sistemas externos cuando ocurren eventos de autenticación — como la creación de usuarios, el inicio de sesión, los cambios de contraseña, las asignaciones de roles y más. En lugar de hacer polling a la API de Auris para detectar cambios, tu servidor recibe notificaciones HTTP POST en tiempo real con los detalles del evento.
Accede a la gestión de webhooks en Consola → Configuración → Webhooks.
Resumen de Webhooks
La página de Webhooks muestra todos los endpoints de webhook configurados para tu tenant:
| Columna | Descripción |
|---|---|
| Nombre | Un nombre descriptivo para el webhook |
| URL | El endpoint al que Auris enviará los eventos |
| Eventos | Número de tipos de eventos suscritos |
| Estado | Activo (verde) o Inactivo (gris) |
| Último Uso | Marca de tiempo de la entrega más reciente |
| Error | Mensaje de error más reciente (si la última entrega falló) |
Crear un Webhook
Hacer clic en Crear Webhook
Desde la página de lista de Webhooks, haz clic en el botón Crear Webhook.
Introducir los detalles del webhook
| Campo | Requerido | Descripción |
|---|---|---|
| Nombre | Sí | Un nombre descriptivo (por ejemplo, “Notificaciones de Slack”, “Pipeline de Analytics”, “Sincronización CRM”) |
| URL | Sí | El endpoint HTTPS que recibirá los payloads de webhook. Debe ser una URL válida que comience con https://. |
| Descripción | No | Contexto adicional sobre para qué se usa este webhook |
Seleccionar eventos
Elige qué eventos debe recibir este webhook. Los eventos están organizados en categorías:
| Categoría | Eventos de Ejemplo |
|---|---|
| Autenticación | user.login, user.logout, user.signup, user.password_changed |
| Usuarios | user.created, user.updated, user.deleted, user.email_verified |
| Roles | role.created, role.updated, role.deleted, role.assigned, role.unassigned |
| Aplicaciones | application.created, application.updated, application.deleted |
| Organizaciones | organization.created, member.added, member.removed, invitation.sent |
| MFA | mfa.enabled, mfa.disabled, mfa.challenge_completed |
| Sesiones | session.created, session.revoked |
| Webhooks | webhook.created, webhook.test |
Haz clic en eventos individuales para seleccionarlos, o usa los controles Seleccionar Todo / Deseleccionar Todo dentro de cada categoría.
Comienza suscribiéndote solo a los eventos que necesitas. Cada evento genera un intento de entrega, y las suscripciones excesivas pueden crear una carga innecesaria en tu endpoint receptor. Siempre puedes añadir más eventos más tarde.
Guardar
Haz clic en Guardar. El webhook se crea en estado activo de forma predeterminada.
Secreto del Webhook
Cada webhook recibe un secreto de firma al crearse. Este secreto se usa para generar firmas HMAC-SHA256 para cada entrega, permitiendo a tu servidor verificar que los webhooks entrantes provienen genuinamente de Auris.
Ver el Secreto
El secreto de firma se muestra una vez inmediatamente después de la creación del webhook en un diálogo de confirmación. Lleva el prefijo whsec_ para una fácil identificación:
whsec_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6Copia el secreto y guárdalo de forma segura en las variables de entorno de tu aplicación. El secreto no se vuelve a mostrar después de que cierras el diálogo.
Si pierdes el secreto del webhook, no puedes recuperarlo. Debes rotar el secreto para generar uno nuevo. Consulta Rotar Secretos.
Verificar Firmas de Webhook
Cada entrega de webhook incluye dos cabeceras para la verificación de firmas:
| Cabecera | Descripción |
|---|---|
X-Webhook-Signature | Firma HMAC-SHA256 del cuerpo de la solicitud usando el secreto del webhook |
X-Webhook-Timestamp | Marca de tiempo Unix de cuando se envió la entrega (para protección contra repetición) |
Pasos de verificación en tu servidor:
- Lee la cabecera
X-Webhook-Timestamp - Verifica que la marca de tiempo está dentro de una ventana aceptable (por ejemplo, 5 minutos) para prevenir ataques de repetición
- Calcula
HMAC-SHA256(timestamp + "." + requestBody, webhookSecret) - Compara la firma calculada con la cabecera
X-Webhook-Signature
Ejemplo de verificación en Node.js:
import { createHmac, timingSafeEqual } from 'crypto'
function verifyWebhook(
body: string,
signature: string,
timestamp: string,
secret: string
): boolean {
// Comprueba la vigencia de la marca de tiempo (ventana de 5 minutos)
const now = Math.floor(Date.now() / 1000)
if (Math.abs(now - parseInt(timestamp)) > 300) {
return false // Demasiado antiguo o demasiado adelantado
}
// Calcula la firma esperada
const payload = `${timestamp}.${body}`
const expected = createHmac('sha256', secret)
.update(payload)
.digest('hex')
// Comparación en tiempo constante para prevenir ataques de temporización
return timingSafeEqual(
Buffer.from(signature),
Buffer.from(expected)
)
}Probar Webhooks
Antes de desplegar en producción, verifica que tu endpoint recibe y procesa correctamente los payloads de webhook.
Enviar Evento de Prueba
En la página de detalles del webhook, haz clic en el botón Probar. Auris envía un evento de prueba a la URL configurada con un payload de ejemplo:
{
"event": "webhook.test",
"timestamp": "2025-02-10T08:15:00Z",
"data": {
"message": "Esta es una entrega de webhook de prueba de Auris."
}
}La entrega de prueba aparece en el log de Entregas, para que puedas verificar el código de estado de respuesta y ver cualquier mensaje de error.
Usar Herramientas de Prueba de Webhooks
Para el desarrollo, puedes usar un servicio de prueba de webhooks como webhook.site o ngrok para recibir e inspeccionar los payloads de webhook:
- Crea una URL temporal usando tu herramienta de prueba
- Establece esa URL como el endpoint del webhook en la Consola
- Activa eventos (por ejemplo, crea un usuario de prueba)
- Inspecciona el payload recibido en la herramienta de prueba
- Actualiza la URL del webhook a tu endpoint de producción cuando estés listo
Ver Entregas
Cada endpoint de webhook tiene un log de entregas que muestra cada evento enviado a él.
Accede al log de entregas haciendo clic en cualquier webhook de la lista para abrir la página de detalles, luego desplázate a la sección Entregas.
| Columna | Descripción |
|---|---|
| Evento | El tipo de evento (por ejemplo, user.created) |
| Estado | Código de estado HTTP devuelto por tu endpoint |
| Marca de Tiempo | Cuándo se envió la entrega |
| Duración | Tiempo de ida y vuelta en milisegundos |
| Intentos | Número de intentos de entrega (1 para éxito, 2-3 para reintentos) |
Estados de Entrega
| Código de Estado | Significado |
|---|---|
| 2xx (200, 201, 204) | Éxito — tu endpoint reconoció la entrega |
| 4xx | Error del cliente — tu endpoint rechazó el payload (no se reintentará) |
| 5xx | Error del servidor — tu endpoint tuvo un fallo temporal (se reintentará) |
| Tiempo de Espera | Tu endpoint no respondió en 10 segundos |
| Error de Red | La resolución DNS falló o la conexión fue rechazada |
Haz clic en cualquier fila de entrega para ver los detalles completos:
- Payload de solicitud: El cuerpo JSON enviado a tu endpoint
- Cuerpo de respuesta: La respuesta devuelta por tu endpoint (primeros 1 KB)
- Cabeceras de respuesta: Cabeceras HTTP devueltas
- Mensaje de error: Si la entrega falló, el error específico
Reintentar Entregas Fallidas
Auris reintenta automáticamente las entregas fallidas (5xx, tiempo de espera, errores de red) con retroceso exponencial:
| Intento | Retraso Después del Fallo |
|---|---|
| 1.er reintento | 30 segundos |
| 2.º reintento | 2 minutos |
| 3.er reintento | 10 minutos |
Después de 3 intentos fallidos, la entrega se marca como fallida y no se producen más reintentos automáticos.
Reintento Manual
Para reintentar manualmente una entrega fallida:
- Abre la página de detalles del webhook
- Encuentra la entrega fallida en el log
- Haz clic en el botón Reintentar en esa fila de entrega
El reintento manual envía exactamente el mismo payload a la URL actual del webhook. Si has cambiado la URL desde la entrega original, el reintento va a la nueva URL.
Si un webhook falla constantemente, Auris muestra una insignia de error en el webhook en la vista de lista. Consulta el log de entregas para obtener detalles del error. Causas comunes: el endpoint está caído, el certificado SSL ha expirado, el endpoint devuelve 401 (autenticación requerida) o tiempo de espera de respuesta (el endpoint es demasiado lento).
Rotar Secretos
Si sospechas que un secreto de webhook ha sido comprometido, o si necesitas rotar secretos como parte de una política de seguridad, puedes generar un nuevo secreto:
Abrir la página de detalles del webhook
Haz clic en el webhook en la lista para abrir su vista de detalles.
Hacer clic en Rotar Secreto
Haz clic en el botón Rotar Secreto (o encuéntralo en el menú desplegable de acciones).
Confirmar la rotación
Aparece un diálogo de confirmación advirtiendo que el secreto anterior se invalidará inmediatamente. Haz clic en Rotar para confirmar.
Copiar el nuevo secreto
El nuevo secreto whsec_ se muestra una vez. Cópialo y actualiza las variables de entorno de tu aplicación.
Importante: La rotación es inmediata. En cuanto rotas, el secreto anterior es inválido y todas las entregas posteriores se firman con el nuevo secreto. Si tu endpoint todavía está configurado con el secreto antiguo, rechazará las entregas hasta que lo actualices. Planifica una breve ventana de entregas fallidas durante la rotación.
Para minimizar las interrupciones:
- Actualiza el código de tu endpoint para aceptar firmas del secreto antiguo o nuevo
- Rota el secreto en la Consola
- Después de confirmar que las entregas tienen éxito con el nuevo secreto, elimina el secreto antiguo del código de tu endpoint
Habilitar y Deshabilitar Webhooks
Cada webhook tiene un interruptor Activo en su página de detalles. Cuando está deshabilitado:
- No se entregan eventos al endpoint
- La configuración del webhook se preserva (URL, eventos, secreto)
- No aparecen entregas en el log mientras está deshabilitado
- Al volver a habilitar, se reanudan las entregas para nuevos eventos (los eventos que ocurrieron mientras estaba deshabilitado no se reproducen)
Usa esto para pausar temporalmente las entregas durante el mantenimiento del endpoint sin perder la configuración del webhook.
Resumen de Categorías de Eventos
Auris admite más de 50 tipos de eventos de webhook, organizados en las siguientes categorías:
| Categoría | Eventos | Descripción |
|---|---|---|
| Autenticación | 8 eventos | Inicio de sesión, cierre de sesión, registro, cambios de contraseña, eventos MFA |
| Usuarios | 6 eventos | CRUD de usuarios, verificación de email, actualizaciones de metadatos |
| Roles | 5 eventos | CRUD de roles, asignación/desasignación de roles |
| Aplicaciones | 4 eventos | CRUD de aplicaciones, rotación de secretos |
| Organizaciones | 6 eventos | CRUD de organizaciones, gestión de miembros, invitaciones |
| Sesiones | 3 eventos | Creación de sesiones, actualización, revocación |
| Tokens | 3 eventos | Emisión de tokens, actualización, revocación |
| FGA | 4 eventos | Activación de modelo, cambios de tupla |
| Webhooks | 2 eventos | Creación de webhook, eventos de prueba |
| SCIM | 4 eventos | Eventos de sincronización de aprovisionamiento SCIM |
Cada payload de evento sigue una estructura consistente:
{
"event": "user.created",
"timestamp": "2025-02-10T08:15:00Z",
"tenantId": "acme-corp",
"data": {
// Payload específico del evento
}
}El campo data varía según el tipo de evento y contiene los datos de la entidad relevante en el momento del evento.
Guías Relacionadas
- Integración de Webhooks — Guía para Desarrolladores — Construir un consumidor de webhooks con verificación de firmas
- Motor de Acciones — Alternativa para la lógica dentro del flujo (se ejecuta durante la autenticación, no después)
- Registros de Auditoría — Ver todos los eventos de autenticación con pistas de auditoría completas