Construir Video Login sin contraseña con Silent Auth y el Video API

La autenticación de vídeo en tiempo real sin contraseña reduce la fricción antes de que comience una sesión en directo y mejora las tasas de conversión de la incorporación. Las contraseñas y los códigos de un solo uso pueden ralentizar a los usuarios. Esto aumenta el riesgo de sesiones abandonadas.

API de red de Vonage trasladan la autenticación a la capa de red móvil, reduciendo la fricción. Con autenticación silenciosa (Silent Auth)-disponible a través de la Verify API de Vonage-el sistema puede verificar que el usuario es el propietario del dispositivo automáticamente analizando el tráfico de red del dispositivo, lo que permite iniciar experiencias en tiempo real sin interrupciones.

En este artículo, veremos cómo Silent Auth puede combinarse con la API de Video de Vonage para crear un flujo de incorporación sin contraseña para Video en tiempo real. Este tutorial explora un patrón de arquitectura reutilizable e incluye fragmentos de código específicos que destacan las decisiones de implementación clave.

TL;DR: Vaya por delante y encontrar el código de trabajo para esta muestra en GitHub.

Requisitos previos

Para seguir esta demostración, necesitarás:

• Una cuenta API de Vonage.

• Python 3.9 o posterior.

• Android Studio.

• Dispositivo físico Android con una SIM habilitada para datos móviles.

Vonage API Account

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

Ready to start building?

Experience seamless connectivity, real-time messaging, and crystal-clear voice and video calls—all at your fingertips.

Cómo funciona la autenticación por Video en tiempo real sin contraseña con Silent Auth

A continuación se explica cómo la autenticación basada en red y el video onboarding pueden trabajar juntos sin estar estrechamente acoplados.

La aplicación verifica el número de teléfono de un usuario utilizando Silent Auth cuando es compatiblecon un SMS sólo cuando es necesario. Una vez realizada la verificación, se genera un token de Video y el usuario se une a la sesión.

La autenticación finaliza antes de que comience el vídeo, por lo que los usuarios disfrutan de una experiencia uniforme independientemente de cómo se hayan verificado.

He aquí cómo es ese flujo en la práctica:

Casos extremos del mundo real

Silent Auth depende del operador. Si el operador de telefonía móvil no admite la verificación basada en red, la Verify API devuelve HTTP 412. En la documentación. Los operadores compatibles varían según el país y pueden cambiar con el tiempo.

En esta aplicación de demostración, los SMS fallback se implementan a nivel de aplicación para los números no soportados. Además de SMS, otros canales de verificación como RCS y WhatsApp.

Para uso en producción, el registro en el Registro de red es necesario. En un entorno de pruebas, puede utilizar el Operadora Virtual sin un dispositivo físico, o registrar un número compatible en el Registro de red Playground y utilizar un dispositivo físico con él.

Aspectos clave de la autenticación silenciosa

Varios detalles de implementación son importantes cuando se trabaja con Silent Auth. Juntos, estos elementos permiten integrar Silent Auth de forma predecible y centrada en la UX.

1. La autenticación silenciosa sólo funciona cuando la solicitud de verificación se envía a través de la red del operador de telefonía móvil, no por Wi-Fi. Esto suele implicar la integración de una biblioteca cliente capaz de forzar la solicitud a través de datos celulares.

2. En esta implementación, confiamos en el comportamiento por defecto coverage_check=true para determinar la ruta de autenticación. Este indicador indica a Verify API que evalúe automáticamente si Silent Auth es compatible con el número dado antes de iniciar la verificación. Si el número es compatible, la aplicación procede con la autenticación silenciosa; de lo contrario, vuelve a la verificación por SMS. Consulte la Documentación de comprobación de cobertura para obtener más información.

3. Esta implementación utiliza Silent Auth flujo síncrono. En este modelo, el backend recibe el check_url directamente de la respuesta de la Verify API, por lo que no es necesario gestionar la devolución de llamada del frontend.

Funcionamiento conjunto del backend y el cliente Android

En esta implementación, el backend Python es el propietario del ciclo de vida de la verificación utilizando el SDK de Python de Vonage. El cliente Android Kotlin utiliza el SDK para Android de Vonage Video para la sesión, y una biblioteca Android de red de operador para ejecutar la función check_url en la red del operador.

1. El cliente Android está configurado con una URL base backend.

object ServerConfig {
    const val CHAT_SERVER_URL: String = "" // Replace with your backend URL
}

2. Retrofit utiliza esta URL base para llamar a los puntos finales de verificación backend.

retrofit = Retrofit.Builder()
    .baseUrl(ServerConfig.CHAT_SERVER_URL)
    .addConverterFactory(MoshiConverterFactory.create())
    .client(client)
    .build().also {
        apiService = it.create(APIService::class.java)
    }

3. El cliente puede llamar y enviar un número de teléfono al backend.

apiService?.startVerify(StartVerifyRequest(phone_number = phoneNumber))

4. El backend inicia la verificación. Con coverage_check=true (por defecto), Verify API determina si Silent Auth es compatible con el operador de destino.

• Si se admite, un URL_de_comprobación se devuelve.

• Si no es compatible, la Verify API responde con HTTP 412, y el backend cambia explícitamente al canal SMS.

def verify_start(body: StartVerifyIn):
    try:
        silent_req = VerifyRequest(
            brand="DemoApp",
            workflow=[SilentAuthChannel(to=body.phone_number)],
            coverage_check=True # Checks whether Silent Auth is supported
        )

        verify_resp = client.verify.start_verification(silent_req) # Initiates Silent Auth verification

        return {
            "request_id": verify_resp.request_id,
            "check_url": getattr(verify_resp, "check_url", None),
            "channel": "silent_auth",
        }

    except HttpRequestError as e:
        if e.response and e.response.status_code == 412:
            sms_req = VerifyRequest(
                brand="DemoApp",
                workflow=[SmsChannel(to=body.phone_number)],
            )

            verify_resp2 = client.verify.start_verification(sms_req) # Fallback to SMS verification

            return {
                "request_id": verify_resp2.request_id,
                "channel": "sms",
            }

        raise

5. El backend devuelve el canal seleccionado junto con los identificadores requeridos por el cliente.

{
    "channel": "silent_auth",
    "request_id": "...",
    "check_url": "https://..."
} 

• indica al cliente qué ruta de UI debe tomar (silent_auth o sms).

• request_id es necesario más tarde para confirmar el resultado de la verificación.

• check_url sólo está presente cuando silent_auth está seleccionado.

6. Si silent_auth, Android ejecuta el comando check_url a través de la red del operador.

Silent Auth requiere que el flujo de redirección se ejecute a través de la red del operador de telefonía móvil, no Wi-Fi. El cliente Android utiliza la biblioteca de peticiones celulares para forzar esta petición a través de datos móviles. La implementación completa de runSilentAuthCheck(), incluida la ejecución en la red del operador y la gestión de la respuesta, está disponible en el repositorio de repositorio GitHub.

when (body.channel) {
    "silent_auth" -> runSilentAuthCheck()
    "sms" -> showSmsUi(true)
}

7. Android envía el código al backend para confirmar la verificación

El cliente no decide el éxito por sí mismo. En su lugar, reenvía el código al backend, que confirma la finalización con la Verify API.

apiService?.confirmVerify(ConfirmVerifyRequest(request_id = rid, code = code))

En el backend, esto se corresponde con una llamada de confirmación de Verify API. El backend devuelve un estado simple para que el cliente pueda continuar.

def verify_confirm_silent(body: ConfirmVerifyIn):
    verify_response = client.verify.check_code(body.request_id, body.code)
    if isinstance(verify_response, str):
        return {"status": verify_response}

    return {"status": getattr(verify_response, "status", str(verify_response))}

Si el estado es completado, se realiza la verificación. En caso contrario, la aplicación permanece en el flujo de autenticación (reintento / reintroducción del código).

8. Una vez completada la verificación, el backend emite un token de Video.

token_options = TokenOptions(
    session_id=os.environ["VONAGE_VIDEO_SESSION_ID"], role="publisher"
)

token = client.video.generate_client_token(token_options)

return {
    "apiKey": os.environ["VONAGE_APPLICATION_ID"],
    "sessionId": os.environ["VONAGE_VIDEO_SESSION_ID"],
    "token": token,
}

9. A continuación, el cliente Android inicializa el SDK de Video Android y se une a la sesión utilizando las credenciales emitidas.

if (status == "completed") {
    initializeSession(apiKey, sessionId, token)
}

Extensión de este patrón a API y plataformas

La implementación presentada aquí utiliza un backend Python y Android para conectar Silent Auth y las funciones de la Video API, pero esta arquitectura puede utilizarse para muchos otros patrones.

Más allá de la autenticación silenciosa

Silent Auth es sólo una de las diversas API de red. Otras señales de red -como SIM Swap o Localización del dispositivo - pueden evaluarse antes de conceder el acceso. Podría exigir la validación de SIM Swap antes de permitir el acceso a consultas de Video de alto valor. Cada API proporciona una señal de confianza, mientras que la aplicación decide cómo actuar en consecuencia.

Verify no es específico de Python

Aunque este artículo demuestra la verificación utilizando el SDK Python de Vonage Verify, el mismo flujo de Verify puede implementarse utilizando otros SDK del lado del servidor compatiblesincluidos Node.js, PHP y otros. El patrón arquitectónico permanece inalterado. También tenemos un ejemplo práctico de Silent Auth dentro del flujo de trabajo de Laravel PHP.

Ejecución basada en operador en iOS

Aunque este ejemplo utiliza Android para ejecución de red basada en operadortambién está disponible en iOS. Silent Auth sigue requiriendo que la solicitud se ejecute a través de la red del operador de telefonía móvil en lugar de Wi-Fi, independientemente de la plataforma.

El SDK de Video es multiplataforma

La capa de sesión de Video no es específica de Android. El SDK de Video de Vonage está disponible en todas las plataformasincluyendo iOS, permitiendo que el mismo patrón de "verificar primero, luego unirse" se aplique de manera consistente.

Conclusión

En este tutorial, creaste un flujo de autenticación de video en tiempo real sin contraseña usando Silent Auth y la Video API de Vonage. Al separar la verificación de la inicialización de la sesión, obtienes flexibilidad, seguridad y un diseño de autenticación preparado para el futuro.