Autenticación silenciosa - Buenas prácticas
Eludir el WiFi y forzar la conexión de datos móviles con los SDK
La autenticación silenciosa requiere una conexión de datos móviles activa. Si la solicitud se realiza a través de Wi-Fi, se producirá un error. Para garantizar una solicitud exitosa incluso cuando el usuario está en WiFi, Vonage ofrece servicios nativos de iOS y Android SDKs que imponen una conexión de datos móviles.
El uso de los SDK también ayuda a minimizar el impacto en la experiencia del usuario en casos extremos:
- Comprobaciones de conectividad (por ejemplo
sdk_no_data_connectivity) para que pueda activar una conmutación por error más rápida y sin interrupciones. - Gestión del tiempo de espera entre redireccionamientos para reducir la espera en condiciones de datos móviles lentos.
- Compatible con iOS 26 en los mercados aplicables (por ejemplo, España).
Además, los SDK de Vonage manejan redireccionamientos HTTP (hasta 10) y administran los tiempos de espera (5 segundos, que se restablecen después de cada redireccionamiento).
Front-end
La autenticación silenciosa dentro de Verify presenta una forma fácil y directa de autenticar a un usuario, proporcionando una experiencia de usuario mejorada en comparación con otros canales.
En los casos de creación de cuentas nuevas, la aplicación móvil no conocerá el número de teléfono del usuario final, por lo que deberá introducirlo en un campo de la pantalla de bienvenida. Alternativamente, un usuario final que ya tiene una cuenta y está intentando iniciar sesión sin contraseña ya tendrá su número de teléfono almacenado. En este caso, el usuario final podría ser presentado con campos de texto pre-rellenados y la única acción necesaria es seleccionar "Verify".
Durante la experiencia de autenticación silenciosa, asegúrese de que el usuario está familiarizado con el proceso y es consciente de que el proceso de autenticación se está ejecutando en segundo plano.
Estado en curso
Para establecer expectativas mientras la autenticación se ejecuta en segundo plano, se recomienda:
- Presente una rueda giratoria o un mecanismo de retroalimentación similar para que el usuario final sepa que la aplicación móvil está trabajando en la tarea de autenticación.
- Alternativamente, muestre una pantalla dedicada con el mismo indicador de carga y texto adicional.
Camino del éxito
Si la autenticación silenciosa se completa correctamente, el usuario debe ser llevado a un estado de éxito claro sin necesidad de introducir un código.
Ruta de retorno
En caso de fallo durante el flujo de autenticación silenciosa, es necesario ajustar el front-end de la aplicación para que el usuario pueda introducir el código pin para completar el proceso 2FA. Este código se entregará a través de los canales de conmutación por error.
A modo de resumen, la siguiente figura ilustra ambos recorridos del usuario: el camino del éxito (la autenticación silenciosa se completa en segundo plano) y el botón ruta alternativa (se pide al usuario que introduzca un código de conmutación por error).
Gestión de errores y tiempos de espera en la autenticación silenciosa
Debido a su naturaleza, la autenticación silenciosa puede verse afectada por condiciones externas como la falta de conectividad de datos móviles o interrupciones temporales de la red. Para garantizar una experiencia de usuario fluida, su aplicación móvil debe confiar en la Biblioteca de clientesen lugar de implementar sus propias comprobaciones de red y gestión del tiempo de espera.
Cuando el SDK encuentra un problema, lanza excepciones específicas que indican qué ha ido mal. Por ejemplo, sdk_no_data_connectivityse lanza cuando no hay conexión de datos móviles disponible.
Evite iniciar la autenticación silenciosa sin datos móviles
Para disfrutar de la mejor experiencia de usuario, comprueba la conectividad de datos móviles. antes de iniciar una solicitud de autenticación silenciosa.
Si el dispositivo no tiene una conexión de datos móviles activa, no inicie el paso de Autenticación silenciosa y pase directamente al siguiente canal de verificación (SMS, RCS, voz, etc.). Esto evita intentos de solicitud innecesarios y reduce el tiempo total de verificación.
Nota: En Biblioteca de clientes actualmente valida la conectividad durante la ejecución. Lanza excepciones (como sdk_no_data_connectivity) cuando se detectan problemas después de que se haya iniciado la solicitud. Véase Comportamiento del tiempo de espera para saber cómo manejar estas excepciones en tiempo de ejecución.
Comportamiento del tiempo de espera
Su aplicación debe detectar estas excepciones y notificar a su backend para que llame a la función next_workflow inmediatamente. Esto garantiza que el flujo de verificación continúe correctamente incluso cuando el flujo de trabajo de autenticación silenciosa falle o no pueda continuar.
Si la aplicación móvil no realiza ninguna acción para pasar al siguiente flujo de trabajo, el sistema se desconectará automáticamente transcurridos 60 segundos y pasará al siguiente flujo de trabajo.
El siguiente diagrama de secuencia ilustra una situación en la que la aplicación móvil no recibe correctamente las redirecciones, posiblemente debido a problemas de red durante la solicitud de check_url:
Caudal recomendado
- Inicie la solicitud de autenticación silenciosa mediante el SDK.
- Si el SDK lanza una excepción (por ejemplo,
sdk_no_data_connectivity), captúralo y llama inmediatamente al backendnext_workflowpunto final. - Si no se recibe ninguna respuesta o devolución de llamada dentro del tiempo de espera interno de su aplicación (por ejemplo, antes de los 60 segundos predeterminados), llame a
next_workflowtambién. - En caso contrario, espera a la llamada de retorno de autenticación normal.
Este enfoque minimiza el tiempo de espera, mejora la experiencia del usuario y garantiza que su backend avance siempre al paso correcto del flujo de trabajo.
Escenarios de conmutación por error
En esta sección enumeramos todos los escenarios que pueden producirse durante una solicitud de autenticación silenciosa y aconsejamos implementaciones de conmutación por error para garantizar la mejor experiencia del usuario final.
Algunos escenarios activan una conmutación por error inmediata al siguiente canal, sin embargo hay casos en los que la conmutación por error sólo se activa después del tiempo de espera predeterminado de Autenticación silenciosa de 60 segundos. Consulte la tabla siguiente, que resume los distintos escenarios de fallo:
| Escenario | Motivo del fallo | Código de fallo | Respuesta al fracaso | ¿Fallo inmediato? |
|---|---|---|---|---|
| 1 | Error de autenticación silenciosa | HTTP 409 | { "title": "Silent Auth error", "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."} | Sí |
| 2 | Error MSISDN | HTTP 409 | { "title": "MSISDN Error", "detail": "Device MSISDN does not match."} | Sí |
| 3 | Red no soportada | HTTP 412 | { "title": "Network not supported", "detail": "Device number does not resolve to a supported Mobile Network Operator."} | Sí |
| 4 | Error IP | HTTP 412 | { "title": "IP Error", "detail": "IP Address does not resolve to a cellular device."} | Sí |
| 5 | Errores del SDK de iOS/Android | -- | sdk_no_data_connectivity, sdk_connection_error, sdk_redirect_error, sdk_error | No |
Facturación de autenticación silenciosa
Cuando se inicia una solicitud de Autenticación Silenciosa, se genera una entrada para la tarifa de la plataforma Verify y una o dos entradas adicionales que representan el uso de la Autenticación Silenciosa. La entrada marcada como INITIATED nunca se factura. En total, una sola solicitud de autenticación silenciosa puede tener hasta tres registros asociados.
Pruebas
Para probar Verify Silent Authentication, puede hacer lo siguiente:
- Utilice Números virtuales.
- Permitir listar los números de las redes admitidas a través de la opción Registro de red.
Si un cliente necesita enviar tráfico en directo, debe registrarse en el operador de telefonía móvil a través de la aplicación Registro de red.