Construire une connexion vidéo sans mot de passe avec Silent Auth et l'API Video

L'authentification vidéo en temps réel sans mot de passe réduit les frictions avant le début d'une session en direct et améliore les taux de conversion de l'onboarding. Les mots de passe et les codes à usage unique peuvent ralentir les utilisateurs. Cela augmente le risque de sessions abandonnées.

API du réseau Vonage transfèrent l'authentification à la couche du réseau mobile, réduisant ainsi les frictions. Avec Authentification silencieuse (Silent Auth)-disponible via l'API Verify API de Vonage-le système peut vérifier que l'utilisateur possède l'appareil automatiquement en analysant le trafic réseau de l'appareil, ce qui permet aux expériences en temps réel de démarrer sans interruption.

Dans cet article, nous verrons comment Silent Auth peut être combiné avec l'API vidéo de Video API de Vonage de Vonage pour créer un flux d'accueil sans mot de passe pour la Video en temps réel. Ce tutoriel explore un modèle d'architecture réutilisable et inclut des extraits de code ciblés qui mettent en évidence les principales décisions de mise en œuvre.

TL;DR : Passez à l'étape suivante et trouvez le code de travail de cet exemple sur GitHub.

Conditions préalables

Pour suivre cette démo, vous aurez besoin de :

• Un compte API Vonage.

• Python 3.9 ou supérieur.

• Android Studio.

• Appareil physique Android doté d'une carte SIM permettant l'accès aux données mobiles.

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.

Comment fonctionne l'authentification vidéo en temps réel sans mot de passe avec Silent Auth

Voici comment l'authentification basée sur le réseau et l'onboarding vidéo peuvent fonctionner ensemble sans être étroitement liés.

L'application vérifie le numéro de téléphone de l'utilisateur à l'aide de l'authentification silencieuse. lorsqu'elle est prise en chargeL'application vérifie le numéro de téléphone de l'utilisateur au moyen de l'authentification silencieuse, avec un SMS automatique uniquement en cas de besoin. Une fois la vérification réussie, un jeton Video est généré et l'utilisateur rejoint la session.

L'authentification se termine avant le début de la vidéo, de sorte que les internautes bénéficient d'une expérience cohérente, quelle que soit la manière dont ils ont été vérifiés.

Voici à quoi ressemble ce flux dans la pratique :

Traiter les cas marginaux du monde réel

L'authentification silencieuse dépend de l'opérateur. Si l'opérateur mobile ne prend pas en charge la vérification basée sur le réseau, l'API Verify renvoie HTTP 412. Une liste des opérateurs mobiles pris en charge par pays est disponible dans la documentation. Les opérateurs pris en charge varient selon les pays et peuvent changer au fil du temps.

Dans cette application de démonstration, la solution de secours par SMS est mise en œuvre au niveau de l'application pour les numéros non pris en charge. En plus du SMS, d'autres canaux de vérification tels que RCS et WhatsApp sont également disponibles.

Pour une utilisation en production, l'enregistrement auprès du Registre du réseau est nécessaire. Dans un environnement de test, vous pouvez utiliser l'option Opérateur virtuel sans dispositif physique, ou enregistrer un numéro pris en charge dans le aire de jeu du Registre du réseau et utiliser un appareil physique avec celui-ci.

Principales considérations relatives à la mise en œuvre de l'authentification silencieuse

Plusieurs détails de mise en œuvre sont importants lorsque l'on travaille avec Silent Auth. Ensemble, ces éléments permettent d'intégrer Silent Auth d'une manière prévisible et axée sur l'expérience utilisateur.

1. L'authentification silencieuse ne fonctionne que lorsque la demande de vérification est envoyée sur le réseau de l'opérateur mobile, et non sur le réseau Wi-Fi. Cela implique généralement l'intégration d'une bibliothèque côté client capable de forcer la demande à passer par des données cellulaires.

2. Dans cette implémentation, nous nous appuyons sur le comportement par défaut pour déterminer le chemin d'authentification. coverage_check=true pour déterminer le chemin d'authentification. Cette option indique à l'API Verify d'évaluer automatiquement si l'authentification silencieuse est prise en charge pour le numéro donné avant de commencer la vérification. Si le numéro est pris en charge, l'application procède à l'authentification silencieuse ; dans le cas contraire, elle revient à la vérification par SMS. Voir la Documentation sur la vérification de la couverture pour plus de détails.

3. Cette mise en œuvre utilise l'authentification silencieuse flux synchrone. Dans ce modèle, le backend reçoit le message check_url directement à partir de la réponse de l'API Verify, de sorte qu'aucune gestion de rappel frontale n'est nécessaire.

Comment le backend et le client Android fonctionnent ensemble

Dans cette implémentation, le backend Python possède le cycle de vie de la vérification en utilisant le SDK Python de Vonage. Le client Android Kotlin utilise le SDK Android Video de Vonage pour la session, et une bibliothèque Android du réseau de l'opérateur pour exécuter la fonction check_url de Silent Auth sur le réseau de l'opérateur.

1. Le client Android est configuré avec une URL de base.

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

2. Retrofit utilise cette URL de base pour appeler les points de vérification du backend.

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

3. Le client peut appeler et envoyer un numéro de téléphone au backend.

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

4. Le backend lance la vérification. Avec coverage_check=true (valeur par défaut), l'API Verify détermine si l'authentification silencieuse est prise en charge pour l'opérateur de destination.

• Si elle est prise en charge, la fonction check_url est renvoyée.

• Si elle n'est pas prise en charge, l'API Verify répond par HTTP 412 et le backend passe explicitement au 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. Le backend renvoie le canal sélectionné avec les identifiants requis par le client.

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

• indique au client quel chemin d'interface utilisateur il doit emprunter (silent_auth ou SMS).

• request_id est nécessaire ultérieurement pour confirmer le résultat de la vérification.

• check_url n'est présent que lorsque silent_auth est sélectionné.

6. Si silent_auth, Android exécute la commande check_url sur le réseau de l'opérateur.

L'authentification silencieuse exige que le flux de redirection soit exécuté sur le réseau de l'opérateur mobile, et non sur le réseau Wi-Fi. Le client Android utilise la bibliothèque de requêtes cellulaires pour forcer cette demande à passer par les données mobiles. L'implémentation complète de runSilentAuthCheck(), y compris l'exécution sur le réseau de l'opérateur et la gestion des réponses, est disponible dans le dépôt dépôt GitHub.

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

7. Android envoie le code au backend pour confirmer la vérification.

Le client ne décide pas lui-même de la réussite. Il transmet le code au backend, qui confirme l'achèvement de l'opération à l'aide de l'API Verify.

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

Sur le backend, cela correspond à un appel de confirmation de l'API Verify. Le backend renvoie un statut simple afin que le client puisse continuer.

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 le statut est terminé, la vérification est effectuée. Dans le cas contraire, l'application reste dans le flux d'authentification (nouvelle tentative / nouvelle saisie du code).

8. Une fois la vérification terminée, le backend émet un jeton 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. Le client Android initialise ensuite le SDK Video Android et rejoint la session à l'aide des informations d'identification émises.

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

Étendre ce modèle aux API et aux plates-formes

La mise en œuvre présentée ici utilise un backend Python et Android pour connecter Silent Auth et les fonctionnalités de Video API, mais cette architecture peut être utilisée pour de nombreux autres modèles.

Au-delà de l'authentification silencieuse

L'authentification silencieuse n'est qu'une API de réseau parmi d'autres. D'autres signaux de réseau, tels que SIM Swap ou localisation de l'appareil - peuvent être évalués avant d'accorder l'accès. Vous pourriez exiger la validation de SIM Swap avant d'autoriser l'accès à des consultations vidéo de grande valeur. Chaque API fournit un signal de confiance, tandis que l'application décide comment agir en conséquence.

Verify n'est pas spécifique à Python

Bien que cet article démontre la vérification à l'aide du SDK Verify Python de Vonage, le même flux de Verify peut être mis en œuvre en utilisant d'autres SDK côté serveur pris en chargecôté serveur, y compris Node.js, PHP et autres. Le modèle architectural reste inchangé. Nous avons également un exemple fonctionnel d'authentification silencieuse dans le flux de travail échafaudé de Laravel PHP.

Exécution par l'opérateur sur iOS

Bien que cet exemple utilise Android pour pour l'exécution du réseau basé sur l'opérateuril est également disponible sur iOS. L'authentification silencieuse exige toujours que la demande soit exécutée sur le réseau de l'opérateur mobile plutôt que sur le Wi-Fi, quelle que soit la plateforme.

Le SDK Video est multiplateforme

La couche de session Video n'est pas spécifique à Android. Le SDK Video de Vonage est disponible sur toutes les plateformesLe SDK vidéo de Vonage est disponible sur toutes les plateformes, y compris iOS, ce qui permet d'appliquer de manière cohérente le même modèle de " vérification d'abord, puis de participation ".

Conclusion

Dans ce tutoriel, vous avez construit un flux d'authentification vidéo en temps réel sans mot de passe à l'aide de Silent Auth et de l'API Video de Vonage. En séparant la vérification de l'initialisation de la session, vous gagnez en flexibilité, en sécurité et en conception d'authentification à l'épreuve du temps.