Capability check
Determina si el destinatario puede recibir RCS según la integración.
RCS puede formar parte de una arquitectura de autenticación, pero no sustituye el diseño de seguridad. La clave está en orquestar disponibilidad, identidad, entrega y fallback sin generar experiencias duplicadas.
La generación, expiración y validación del OTP debe permanecer gobernada por la arquitectura de autenticación. El canal de mensajería es una de las piezas del proceso.
1. backend genera OTP 2. evalúa canal disponible 3. RCS si procede 4. SMS como fallback si la política lo define 5. backend valida OTP 6. código expira
La lógica debe ser determinista: cuándo comprobar capacidad, cuánto esperar, qué eventos confirman envío y en qué momento se recurre a SMS. Eso evita dobles códigos y experiencias confusas.
Determina si el destinatario puede recibir RCS según la integración.
Define ventanas de decisión según el flujo de autenticación.
Evita emitir varios códigos válidos para la misma operación.
Registra qué canal se utilizó y por qué.
Cuida la coherencia entre marca, agente y alias.
No asumas que el canal sustituye controles de seguridad adicionales.
El pilar de autenticación actual basado en SMS.
Ver OTP SMS →Integración del canal RCS.
Ver API →Comparativa de disponibilidad y experiencia.
Comparar →Una arquitectura RCS puede utilizarse para flujos de autenticación cuando el diseño, proveedor y políticas de seguridad lo contemplen.
Puede ser aconsejable cuando la disponibilidad de RCS no está garantizada para todos los destinatarios.
No debe asumirse. La seguridad depende del proceso completo: generación y validación del código, identidad, riesgo, dispositivo, proveedor y controles de cuenta.
Revisamos audiencia, casos de uso, sistemas, identidad del remitente, fallback y encaje con SMS antes de definir arquitectura.