CIBA (Autenticación de Canal Inverso)
Client Initiated Backchannel Authentication (CIBA) es una extensión de OpenID Connect que permite a una aplicación cliente iniciar la autenticación en nombre de un usuario sin requerir que el usuario interactúe directamente con el cliente. En su lugar, el usuario recibe una notificación (por SMS, correo electrónico o push) en un dispositivo separado y aprueba o rechaza la solicitud allí.
Casos de uso comunes:
- Un agente de un centro de atención autentica a un cliente por teléfono desencadenando una aprobación en el dispositivo móvil del cliente
- Un terminal de pago solicita aprobación desde el teléfono del titular de la cuenta antes de procesar una transacción de alto valor
- Una aplicación de escritorio delega el inicio de sesión al teléfono del usuario para una experiencia sin contraseña
- Un servicio backend inicia la autenticación de escalada cuando se solicita una operación sensible
Cómo Funciona
CIBA desacopla el dispositivo donde se inicia la autenticación del dispositivo donde el usuario da su consentimiento:
- El cliente envía una solicitud de autenticación por canal inverso a
/api/oauth/cibacon unlogin_hint(correo, número de teléfono o ID de usuario) que identifica al usuario - Auris valida la solicitud y envía una notificación al usuario en su dispositivo o canal registrado
- El usuario ve los detalles de la solicitud (nombre de la aplicación, mensaje de vinculación) y aprueba o rechaza
- El cliente recibe el resultado mediante uno de tres modos: sondeo, ping (callback) o push
Modos de Notificación
Auris admite tres modos para entregar el resultado de la autenticación al cliente:
| Modo | Cómo Funciona | Más Adecuado Para |
|---|---|---|
| Sondeo | El cliente consulta el endpoint de tokens a intervalos regulares hasta que el usuario responde | Integraciones simples, clientes del lado del servidor |
| Ping | Auris envía una notificación a una URL de callback pre-registrada, luego el cliente intercambia el ID de solicitud de autenticación por un token | Arquitecturas orientadas a eventos |
| Push | Auris entrega el token directamente a una URL de callback pre-registrada | Requisitos de baja latencia |
El modo de sondeo es el más sencillo de implementar y se recomienda para la mayoría de los casos de uso. Los modos ping y push requieren una URL de callback públicamente accesible y una seguridad adecuada del webhook.
Configuración en la Consola
Habilitar CIBA
En la Consola de Auris, ve a Aplicaciones y selecciona tu aplicación. En la pestaña Configuración, activa Habilitar CIBA.
Configurar el Modo de Notificación
Selecciona el modo de notificación (Sondeo, Ping o Push). Para los modos Ping y Push, proporciona una URL de Callback donde Auris enviará las notificaciones.
Establecer el Canal de Notificación
Elige cómo los usuarios reciben la notificación de solicitud de autenticación:
| Canal | Requisitos |
|---|---|
| Correo electrónico | El usuario debe tener una dirección de correo verificada |
| SMS | El usuario debe tener un número de teléfono verificado. Requiere configuración del proveedor SMS (Twilio). |
| Push | Requiere una integración de notificaciones push personalizada (avanzado) |
Configurar la Duración de la Solicitud
Establece el tiempo máximo que una solicitud de autenticación CIBA permanece válida antes de expirar:
| Ajuste | Predeterminado | Notas |
|---|---|---|
| Duración de la solicitud | 300 segundos (5 minutos) | Tiempo máximo que tiene el usuario para aprobar o rechazar |
| Intervalo de sondeo | 5 segundos | Intervalo mínimo para clientes en modo sondeo |
Copiar las Credenciales
CIBA requiere un cliente confidencial. Copia el Client ID y el Client Secret de la pestaña Credenciales.
Implementación
JavaScript (Modo Sondeo)
const AURIS_DOMAIN = 'https://auth.tudominio.com'
const CLIENT_ID = 'tu-client-id'
const CLIENT_SECRET = 'tu-client-secret'
// Paso 1: Iniciar la autenticación por canal inverso
const respuestaCiba = await fetch(`${AURIS_DOMAIN}/api/oauth/ciba`, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic ${btoa(`${CLIENT_ID}:${CLIENT_SECRET}`)}`,
},
body: new URLSearchParams({
scope: 'openid profile',
login_hint: '[email protected]',
binding_message: 'Aprobar inicio de sesión en el Dashboard',
}),
}).then(r => r.json())
console.log('ID de solicitud de autenticación:', respuestaCiba.auth_req_id)
console.log('El usuario recibirá una notificación...')
// Paso 2: Sondear para el token
const token = await sondearTokenCiba(respuestaCiba)
async function sondearTokenCiba(respuestaCiba) {
const interval = respuestaCiba.interval * 1000
const expiresAt = Date.now() + respuestaCiba.expires_in * 1000
while (Date.now() < expiresAt) {
await new Promise(resolve => setTimeout(resolve, interval))
const response = await fetch(`${AURIS_DOMAIN}/api/auth/token`, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic ${btoa(`${CLIENT_ID}:${CLIENT_SECRET}`)}`,
},
body: new URLSearchParams({
grant_type: 'urn:openid:params:grant-type:ciba',
auth_req_id: respuestaCiba.auth_req_id,
}),
})
if (response.ok) {
return await response.json()
}
const error = await response.json()
if (error.error === 'authorization_pending') continue
if (error.error === 'slow_down') {
await new Promise(r => setTimeout(r, 5000))
continue
}
if (error.error === 'expired_token') {
throw new Error('La solicitud CIBA expiró. El usuario no respondió a tiempo.')
}
if (error.error === 'access_denied') {
throw new Error('El usuario rechazó la solicitud de autenticación.')
}
throw new Error(`Error CIBA: ${error.error}`)
}
throw new Error('La solicitud CIBA expiró por tiempo de espera.')
}Parámetros de la Solicitud CIBA
La solicitud de autenticación por canal inverso acepta los siguientes parámetros:
| Parámetro | Obligatorio | Descripción |
|---|---|---|
scope | Sí | Scopes de OpenID Connect (debe incluir openid) |
login_hint | Sí | Identifica al usuario. Puede ser una dirección de correo, número de teléfono o ID de usuario. |
binding_message | No | Mensaje corto mostrado al usuario en la pantalla de aprobación (ej. “Aprobar inicio de sesión en Dashboard”). Máximo 128 caracteres. |
requested_expiry | No | Duración solicitada de la solicitud de autenticación en segundos. Limitada por la configuración de la aplicación. |
acr_values | No | Valores de Clase de Contexto de Autenticación solicitados para autenticación de escalada |
El Mensaje de Vinculación
El binding_message es una característica de seguridad fundamental. Se muestra al usuario en la notificación de aprobación y debe contener suficiente contexto para que el usuario confirme qué está aprobando:
- “Aprobar inicio de sesión en Dashboard” (inicio de sesión)
- “Confirmar pago de EUR 49,99 a ACME Corp” (aprobación de pago)
- “Autorizar al agente de soporte a acceder a tu cuenta” (centro de atención)
Incluye siempre un mensaje de vinculación significativo. Sin él, los usuarios no pueden distinguir una solicitud CIBA legítima de un intento de phishing. El mensaje de vinculación debe ser específico para la acción actual — nunca uses un mensaje genérico “Aprobar inicio de sesión” para pagos u operaciones sensibles.
Gestión de Errores
| Código de error | Estado HTTP | Significado |
|---|---|---|
authorization_pending | 400 | El usuario aún no ha respondido a la notificación |
slow_down | 400 | El cliente está sondeando demasiado rápido |
expired_token | 400 | La solicitud de autenticación ha expirado (el usuario no respondió) |
access_denied | 400 | El usuario rechazó explícitamente la solicitud |
invalid_request | 400 | Parámetros faltantes o inválidos |
unknown_user_id | 400 | El login_hint no coincide con ningún usuario conocido |
unauthorized_client | 401 | El cliente no está autorizado para CIBA |
Consideraciones de Seguridad
- Cliente confidencial requerido: CIBA siempre requiere autenticación del cliente (client ID + secret). Los clientes públicos no pueden usar CIBA.
- Corta duración de la solicitud: 300 segundos por defecto. Duraciones más cortas reducen la ventana para ataques de ingeniería social.
- Consentimiento del usuario requerido: El usuario debe aprobar explícitamente la solicitud. Auris nunca aprueba automáticamente.
- Visualización del mensaje de vinculación: La interfaz de aprobación siempre muestra el mensaje de vinculación, el nombre de la aplicación y los scopes solicitados.
- Verificación del canal de notificación: Auris solo envía notificaciones CIBA a direcciones de correo o números de teléfono verificados.
- Registro de auditoría: Todas las solicitudes CIBA (iniciadas, aprobadas, rechazadas, expiradas) se registran con fines de auditoría.
Endpoints de la API
/api/oauth/cibaInicia una solicitud de autenticación por canal inverso. Requiere autenticación del cliente (autenticación básica o client_id/client_secret en el cuerpo). Devuelve auth_req_id, expires_in e interval.
/api/auth/tokenEndpoint de tokens. Para CIBA, establece grant_type=urn:openid:params:grant-type:ciba y auth_req_id. Devuelve el access token cuando el usuario aprueba, o un código de error durante el sondeo.
/api/oauth/ciba/requestsRequires: view:ciba_requestsLista las solicitudes de autenticación CIBA activas para el tenant. Endpoint de administración para monitorización.
Permisos Necesarios
| Operación | Permiso |
|---|---|
| Habilitar CIBA en una aplicación | manage:applications |
| Configurar ajustes CIBA | manage:ciba_config |
| Listar solicitudes CIBA activas | view:ciba_requests |
| Iniciar/sondear para el token | Solo autenticación del cliente (sin permiso de usuario) |
Guías Relacionadas
- Flujo de Autorización de Dispositivos — Flujo desacoplado similar para dispositivos con entrada limitada
- Hosted Login (PKCE) — Autenticación estándar basada en navegador
- Autenticación Multifactor — CIBA puede integrarse con MFA para autenticación de escalada