CIBA (Autenticación de canal inverso iniciada por el cliente)

El problema: autenticación iniciada por otra persona

Los flujos tradicionales de OAuth 2.0 asumen que un solo usuario interactúa con un solo dispositivo: el usuario abre un navegador, introduce credenciales y recibe tokens — todo en el mismo dispositivo, en la misma sesión. Este modelo funciona para aplicaciones web y móviles, pero falla en escenarios donde la persona que solicita la autenticación no es la misma que se autentica.

Qué es CIBA

CIBA (Client Initiated Backchannel Authentication) es una extensión de OpenID Connect. Permite a una aplicación cliente iniciar un flujo de autenticación para un usuario conocido, donde el usuario se autentica en un dispositivo de autenticación separado (típicamente su teléfono) mediante una notificación push, SMS o email.

La distinción clave de otros flujos OAuth:

• Authorization Code + PKCE: El usuario conduce el flujo de principio a fin en el mismo dispositivo
• Device Flow: El cliente muestra un código, el usuario visita una URL y lo introduce. El usuario inicia la interacción secundaria
• CIBA: El cliente inicia, el servidor envía una notificación push al usuario. El usuario solo reacciona

CIBA desacopla el dispositivo de consumo (donde se ejecuta el servicio) del dispositivo de autenticación (donde el usuario demuestra su identidad).

Cómo funciona CIBA: paso a paso

Paso 1: El cliente envía una solicitud de autenticación de canal inverso

POST /api/oauth/ciba HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer <client_access_token>
 
[email protected]
&scope=openid profile
&binding_message=Autorizar verificación de cuenta para el agente Sarah (ref: TX-9821)
&requested_expiry=120
&client_notification_token=notification-callback-token-xyz

Paso 2: El servidor devuelve un ID de solicitud de autenticación

{
  "auth_req_id": "ciba_req_1a2b3c4d5e6f7g8h",
  "expires_in": 120,
  "interval": 5
}

Paso 3: El servidor notifica al usuario

Auris envía una notificación al dispositivo de autenticación del usuario. El método de entrega depende del modo configurado:

• Poll: El cliente realiza polling al servidor de tokens con el auth_req_id
• Ping: El servidor llama al callback del cliente cuando el usuario responde; el cliente luego recupera los tokens
• Push: El servidor entrega los tokens directamente al endpoint del cliente (el modo más seguro)

El binding_message se muestra al usuario en su dispositivo de autenticación — permite al usuario verificar que la solicitud legítima coincide con lo que el agente les está diciendo.

Paso 4: El usuario aprueba o rechaza

El usuario ve el binding_message y aprueba o rechaza la solicitud en su dispositivo de autenticación. Si tiene MFA configurado, debe completarlo.

Paso 5: El cliente recibe los tokens

En modo poll:

POST /api/auth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
 
grant_type=urn:openid:params:grant-type:ciba
&auth_req_id=ciba_req_1a2b3c4d5e6f7g8h
&client_id=call-center-app

Casos de uso