Skip to Content

Autenticación Multifactor (MFA)

La autenticación multifactor requiere que los usuarios proporcionen una segunda forma de verificación además de sus credenciales principales. Auris soporta cuatro mecanismos de MFA — apps de autenticación TOTP, contraseñas de un solo uso por SMS, claves de hardware WebAuthn y passkeys, y MFA adaptativa basada en riesgo que activa factores adicionales automáticamente según el riesgo detectado — que pueden combinarse según tu política de seguridad.

TOTP (App Autenticadora)

La Contraseña de Un Solo Uso Basada en Tiempo (TOTP) es el mecanismo de MFA más ampliamente soportado. Los usuarios escanean un código QR con una app autenticadora — como Google Authenticator, Authy, 1Password, o cualquier aplicación compatible con RFC 6238 — e introducen el código de seis dígitos que genera.

Cómo funciona

Los códigos TOTP se derivan de un secreto compartido y el tiempo actual. El servidor y la app autenticadora calculan de forma independiente el mismo código para cada ventana de 30 segundos. No se requiere conexión de red en el dispositivo del usuario.

Configuración del usuario

El flujo de registro TOTP:

  1. El usuario navega a Cuenta → Seguridad → Autenticación de Dos Factores.
  2. Se muestra un código QR y una clave de entrada manual.
  3. El usuario escanea el código QR con su app autenticadora.
  4. El usuario introduce el código inicial de seis dígitos para confirmar la configuración.
  5. Se generan y muestran los códigos de recuperación. El usuario debe guardarlos — no se pueden recuperar más tarde.

Códigos de recuperación

Cada configuración TOTP genera 10 códigos de recuperación de un solo uso. Si un usuario pierde acceso a su dispositivo autenticador, puede introducir un código de recuperación para omitir el MFA e iniciar sesión. Tras su uso, un código de recuperación queda invalidado. Los usuarios pueden generar un nuevo conjunto de códigos de recuperación desde su página de seguridad de cuenta — al hacerlo, todos los códigos anteriores quedan invalidados.

Acciones de administrador

Los administradores pueden restablecer el registro TOTP de un usuario a través de la Consola (Detalle de usuario → Seguridad → Restablecer TOTP). Esto elimina la configuración TOTP existente y fuerza al usuario a volver a registrarse en el próximo inicio de sesión. Úsalo cuando un usuario reporte un dispositivo perdido o reemplazado.

POST/api/user/2fa/totp/enable

Inicia el registro TOTP para el usuario autenticado. Devuelve el secreto TOTP y el URI de datos del código QR.

POST/api/user/2fa/totp/verify

Confirma el registro verificando el código TOTP inicial. Genera y devuelve los códigos de recuperación.

DELETE/api/user/2fa/totp

Elimina el registro TOTP del usuario. Requiere el código TOTP actual o un código de recuperación para confirmación.

SMS OTP

Las contraseñas de un solo uso por SMS envían un código de verificación al número de teléfono móvil registrado del usuario mediante SMS. Auris utiliza Twilio como proveedor de SMS.

Requisitos

SMS OTP requiere:

  • Una cuenta Twilio con un número de teléfono capaz de enviar SMS.
  • Las variables de entorno TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN y TWILIO_FROM_NUMBER configuradas en la API de Auris.

Para una guía completa de configuración de SMS OTP incluyendo la configuración de Twilio, consulta Autenticación SMS OTP.

Configuración del usuario

  1. El usuario navega a Cuenta → Seguridad → Número de Teléfono.
  2. El usuario introduce su número de móvil en formato E.164 (p. ej., +39 02 1234 5678).
  3. Auris envía un código de verificación por SMS.
  4. El usuario introduce el código para confirmar la propiedad del teléfono.
  5. El número de teléfono queda verificado y puede usarse para MFA por SMS OTP.

Límites de velocidad

Para prevenir abusos, Auris aplica límites de velocidad en los códigos SMS OTP:

  • Máximo 5 códigos enviados por número de teléfono por hora.
  • Un período de espera de 30 segundos entre solicitudes de envío.
  • Máximo 5 intentos de verificación por código antes de que se invalide.
POST/api/user/phone

Establece el número de teléfono del usuario y envía un código de verificación.

POST/api/user/phone/verify

Verifica el número de teléfono con el código recibido por SMS.

POST/api/user/2fa/sms/enable

Habilita SMS OTP como segundo factor tras verificar el número de teléfono.

POST/api/user/2fa/sms/send

Envía un nuevo código SMS OTP durante un desafío MFA.

WebAuthn / Passkeys

WebAuthn (Web Authentication, FIDO2) permite a los usuarios autenticarse usando claves de seguridad de hardware (YubiKey, Titan Key) o autenticadores de plataforma (Touch ID, Face ID, Windows Hello). Cuando se usa como segundo factor, el usuario toca su clave de hardware o usa biometría para completar el desafío MFA.

Las credenciales WebAuthn son resistentes al phishing por diseño: la credencial está vinculada al origen específico (dominio) y no puede reproducirse en un sitio diferente.

Para una guía completa de configuración de WebAuthn, consulta WebAuthn / Passkeys.

Configuración del usuario

  1. El usuario navega a Cuenta → Seguridad → Passkeys.
  2. El usuario hace clic en “Registrar Passkey” y proporciona un nombre para la credencial.
  3. El navegador presenta un aviso de autenticador de plataforma (Touch ID, Windows Hello, o una clave de hardware).
  4. La credencial queda registrada. El usuario puede registrar múltiples passkeys para diferentes dispositivos.

Durante el desafío MFA

Cuando se requiere MFA con WebAuthn, la página de Login Alojado presenta un desafío WebAuthn. El autenticador registrado del usuario gestiona la respuesta criptográfica — no se necesita introducir ningún código.

POST/api/user/2fa/webauthn/enable

Inicia el registro WebAuthn como segundo factor. Devuelve el desafío de registro.

POST/api/user/2fa/webauthn/challenge

Genera un desafío de autenticación para una verificación MFA en curso.

DELETE/api/user/2fa/webauthn

Elimina una credencial WebAuthn registrada por ID de credencial.

MFA Adaptativa (Basada en Riesgo)

La MFA adaptativa evalúa una puntuación de riesgo en cada inicio de sesión y escala automáticamente el requisito de autenticación cuando el riesgo es elevado. En lugar de requerir MFA siempre o nunca, Auris responde de forma proporcional al riesgo real de cada intento de inicio de sesión.

Factores de riesgo

Auris calcula una puntuación de riesgo a partir de cinco factores ponderados:

FactorDescripciónEjemplo de activación
Reputación de IPDirección IP asociada con actividad maliciosa conocida, VPN, proxy o centro de datosInicio de sesión desde un nodo de salida de Tor
Confianza en el dispositivoHuella digital de dispositivo desconocida (sin inicio de sesión exitoso previo desde este dispositivo)Primer inicio de sesión desde un portátil nuevo
Anomalía geográficaViaje imposible — la distancia entre la ubicación del inicio de sesión anterior y la actual implica un movimiento más rápido de lo posibleInicio de sesión desde Italia seguido 30 minutos después de Japón
Patrones de comportamientoHora de inicio de sesión, cadencia de solicitudes y otras señales de comportamiento que se desvían de la línea base del usuarioInicio de sesión a las 3:00 AM cuando el usuario siempre inicia sesión en horario laboral
Sensibilidad de la acciónLas operaciones de mayor sensibilidad (p. ej., cambiar email, generar claves API) se puntúan con mayor rigor que el acceso de solo lecturaUsuario intentando cambiar su contraseña inmediatamente después del inicio de sesión

Los factores se combinan en una puntuación de riesgo final de 0 a 100.

Umbrales de riesgo

Configura los umbrales en Consola → Seguridad → MFA Adaptativa:

UmbralComportamiento
Bajo (0–30)No se requiere autenticación adicional. El inicio de sesión estándar procede.
Medio (31–70)Solicitar cualquier método MFA configurado (TOTP, SMS o WebAuthn).
Alto (71–100)Requerir un método MFA más robusto. Solo TOTP es insuficiente — se prefiere WebAuthn con hardware.

Estos umbrales son configurables. También puedes deshabilitar la MFA adaptativa por completo y usar una política fija.

ACR y AMR en los tokens

Cuando ocurre la autenticación escalonada, Auris incluye claims estándar en el access token:

  • ACR (Authentication Context Class Reference): El nivel de garantía alcanzado. Por ejemplo, urn:mace:incommon:iap:silver para sesiones verificadas con MFA.
  • AMR (Authentication Methods References): Los métodos de autenticación utilizados. Por ejemplo, ["pwd", "totp"] para contraseña + TOTP, o ["pwd", "hwk"] para contraseña + clave de hardware.

El servidor de tu aplicación puede inspeccionar estos claims para aplicar control de acceso a nivel de sesión.

Autenticación Escalonada (Step-Up)

La autenticación escalonada permite que tu aplicación requiera verificación adicional para operaciones específicas dentro de una sesión existente, sin forzar un inicio de sesión completo.

Por ejemplo, un usuario está conectado y navega a “Eliminar Cuenta”. Tu aplicación puede activar un desafío de step-up que requiera al usuario volver a autenticarse (introducir su contraseña) o completar un factor MFA antes de que proceda la acción destructiva.

Auris implementa el step-up mediante ACR en la solicitud de autorización. Cuando tu aplicación solicita un código de autorización con acr_values=2fa, Auris comprueba el nivel ACR de la sesión actual y solo solicita autenticación adicional si la sesión no cumple ya el requisito.

La autenticación escalonada se basa en los claims AMR de la sesión. A una sesión autenticada con TOTP (amr: ["pwd", "totp"]) no se le pedirá TOTP de nuevo durante la validez de la misma sesión a menos que el requisito ACR especifique un método que no esté ya presente.

Configuración en la Consola

La configuración de MFA está disponible en Consola → Autenticación → Configuración MFA.

Interruptores por método:

MétodoInterruptorNotas
TOTPActivar/DesactivarActiva para permitir a los usuarios registrar apps autenticadoras
SMS OTPActivar/DesactivarRequiere que Twilio esté configurado en las variables de entorno
WebAuthnActivar/DesactivarRequiere HTTPS (las passkeys no funcionan con HTTP plano)
MFA AdaptativaActivar/DesactivarCuando está desactivado, la política estática se aplica a todos los usuarios

Políticas de aplicación:

PolíticaSignificado
optionalLos usuarios pueden configurar MFA pero no están obligados a hacerlo
requiredTodos los usuarios deben registrar al menos un método MFA para completar el inicio de sesión
adaptiveMFA solo se requiere cuando la puntuación de riesgo supera el umbral configurado

Umbrales de riesgo: Controles deslizantes configurables para los límites Bajo/Medio/Alto y los pesos de cada factor.

Permisos Requeridos

Todos los endpoints de gestión de MFA operan sobre la cuenta del propio usuario autenticado y no requieren ningún permiso especial más allá de la autenticación. Las operaciones de nivel administrador (restablecer el TOTP de otro usuario, ver el estado MFA) requieren manage:users.

Páginas Relacionadas

Arquitectura