Skip to Content

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:

  1. El cliente envía una solicitud de autenticación por canal inverso a /api/oauth/ciba con un login_hint (correo, número de teléfono o ID de usuario) que identifica al usuario
  2. Auris valida la solicitud y envía una notificación al usuario en su dispositivo o canal registrado
  3. El usuario ve los detalles de la solicitud (nombre de la aplicación, mensaje de vinculación) y aprueba o rechaza
  4. 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:

ModoCómo FuncionaMás Adecuado Para
SondeoEl cliente consulta el endpoint de tokens a intervalos regulares hasta que el usuario respondeIntegraciones simples, clientes del lado del servidor
PingAuris 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 tokenArquitecturas orientadas a eventos
PushAuris entrega el token directamente a una URL de callback pre-registradaRequisitos 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:

CanalRequisitos
Correo electrónicoEl usuario debe tener una dirección de correo verificada
SMSEl usuario debe tener un número de teléfono verificado. Requiere configuración del proveedor SMS (Twilio).
PushRequiere 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:

AjustePredeterminadoNotas
Duración de la solicitud300 segundos (5 minutos)Tiempo máximo que tiene el usuario para aprobar o rechazar
Intervalo de sondeo5 segundosIntervalo 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

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ámetroObligatorioDescripción
scopeSíScopes de OpenID Connect (debe incluir openid)
login_hintSíIdentifica al usuario. Puede ser una dirección de correo, número de teléfono o ID de usuario.
binding_messageNoMensaje corto mostrado al usuario en la pantalla de aprobación (ej. “Aprobar inicio de sesión en Dashboard”). Máximo 128 caracteres.
requested_expiryNoDuración solicitada de la solicitud de autenticación en segundos. Limitada por la configuración de la aplicación.
acr_valuesNoValores 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 errorEstado HTTPSignificado
authorization_pending400El usuario aún no ha respondido a la notificación
slow_down400El cliente está sondeando demasiado rápido
expired_token400La solicitud de autenticación ha expirado (el usuario no respondió)
access_denied400El usuario rechazó explícitamente la solicitud
invalid_request400Parámetros faltantes o inválidos
unknown_user_id400El login_hint no coincide con ningún usuario conocido
unauthorized_client401El 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

POST/api/oauth/ciba

Inicia 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.

POST/api/auth/token

Endpoint 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.

GET/api/oauth/ciba/requestsRequires: view:ciba_requests

Lista las solicitudes de autenticación CIBA activas para el tenant. Endpoint de administración para monitorización.


Permisos Necesarios

OperaciónPermiso
Habilitar CIBA en una aplicaciónmanage:applications
Configurar ajustes CIBAmanage:ciba_config
Listar solicitudes CIBA activasview:ciba_requests
Iniciar/sondear para el tokenSolo autenticación del cliente (sin permiso de usuario)

Guías Relacionadas