Authentification silencieuse - Meilleures pratiques

Contourner le WiFi et forcer la connexion aux données mobiles avec les SDK

L'authentification silencieuse nécessite une connexion active aux données mobiles. Si la demande est faite par Wi-Fi, elle aboutira à une erreur. Pour garantir la réussite de la demande même lorsque l'utilisateur est en WiFi, Vonage fournit des services natifs d'authentification silencieuse. iOS et Android Les SDK qui imposent une connexion aux données mobiles.

L'utilisation des SDK permet également de minimiser l'impact sur l'interface utilisateur dans les cas particuliers :

Contrôles de connectivité (par exemple sdk_no_data_connectivity) afin de déclencher un basculement plus rapide et transparent.
Gestion des délais entre les redirections pour réduire l'attente dans des conditions de données mobiles lentes.
Prise en charge d'iOS 26 sur les marchés concernés (par exemple l'Espagne).

En outre, les SDK de Vonage gèrent les redirections HTTP (jusqu'à 10) et les délais d'attente (5 secondes, réinitialisation après chaque redirection).

Front-end

L'authentification silencieuse au sein de Verify présente un moyen simple et direct d'authentifier un utilisateur, offrant une expérience utilisateur améliorée par rapport à d'autres canaux.

Pour les cas d'utilisation liés à la création d'un nouveau compte, l'application mobile ne connaîtra pas le numéro de téléphone de l'utilisateur final, qui devra donc être collecté via un champ de saisie sur l'écran d'accueil. Par ailleurs, le numéro de téléphone d'un utilisateur final qui possède déjà un Account et qui tente de se connecter sans mot de passe est déjà enregistré. Dans ce cas, l'utilisateur final pourrait se voir présenter des champs de texte préremplis et la seule action nécessaire est de sélectionner "Verify".

Lors de l'expérience d'authentification silencieuse, assurez-vous que l'utilisateur est familiarisé avec le processus et qu'il est conscient que le processus d'authentification s'exécute en arrière-plan.

État en cours

Pour définir les attentes pendant que l'authentification s'exécute en arrière-plan, il est recommandé de.. :

Présentez une roue tournante ou un mécanisme de retour d'information similaire pour que l'utilisateur final sache que l'application mobile travaille sur la tâche d'authentification.
Il est également possible d'afficher un écran dédié avec le même indicateur de chargement et un texte supplémentaire.

Parcours de réussite

Si l'authentification silencieuse se termine avec succès, l'utilisateur doit être amené à un état de réussite clair sans avoir besoin d'entrer un code.

Chemin de repli

En cas d'échec pendant le flux d'authentification silencieuse, le front-end de l'application doit être ajusté afin que l'utilisateur puisse insérer le code pin pour terminer le processus 2FA. Ce code sera délivré via les canaux de basculement.

En résumé, la figure ci-dessous illustre les deux parcours de l'utilisateur : la voie de la réussite (l'authentification silencieuse s'effectue en arrière-plan) et l'option chemin de repli (l'utilisateur est invité à saisir un code de basculement).

Gestion des erreurs et des délais d'attente dans l'authentification silencieuse

En raison de sa nature, l'authentification silencieuse peut être affectée par des conditions externes telles qu'un manque de connectivité des données mobiles ou des interruptions temporaires du réseau. Pour garantir une expérience utilisateur fluide, votre application mobile doit s'appuyer sur la fonction d'authentification silencieuse. Bibliothèque du clientplutôt que d'implémenter ses propres contrôles réseau et sa propre gestion des délais.

Lorsque le SDK rencontre un problème, il lance des exceptions spécifiques qui indiquent ce qui n'a pas fonctionné. Par exemple, sdk_no_data_connectivityL'application est lancée lorsqu'il n'y a pas de connexion de données mobiles.

Éviter de lancer l'authentification silencieuse sans données mobiles

Pour une meilleure expérience utilisateur, pensez à vérifier la connectivité des données mobiles. avant initier une demande d'authentification silencieuse.

Si l'appareil ne dispose pas d'une connexion de données mobiles active, ne lancez pas l'étape d'authentification silencieuse et passez directement au canal de vérification suivant (SMS, RCS, voix, etc.). Cela permet d'éviter les tentatives de demande inutiles et de réduire la durée totale de la vérification.

Remarque : Les Bibliothèque du client valide actuellement la connectivité pendant l'exécution. Il lève les exceptions (telles que sdk_no_data_connectivity) lorsque des problèmes sont détectés après l'introduction de la demande. Voir Comportement du délai d'attente pour savoir comment gérer ces exceptions d'exécution.

Comportement du délai d'attente

Votre application doit attraper ces exceptions et notifier à votre backend d'appeler la fonction next_workflow immédiatement. Cela permet de garantir que le flux de vérification se poursuit avec élégance, même lorsque le flux de travail de l'authentification silencieuse échoue ou ne peut pas se poursuivre.

Si l'application mobile n'entreprend aucune action pour passer au flux de travail suivant, le système interrompt automatiquement le processus au bout de 60 secondes et passe au flux de travail suivant.

Le diagramme de séquence ci-dessous illustre une situation dans laquelle les redirections ne sont pas correctement reçues par l'application mobile, peut-être en raison de problèmes de réseau lors de la requête de check_url:

Débit recommandé

Lancez la demande d'authentification silencieuse à l'aide du SDK.
Si le SDK lève une exception (par ex, sdk_no_data_connectivity), l'attrape et appelle immédiatement la fonction next_workflow point final.
Si aucune réponse ou rappel n'est reçu dans le délai interne de votre application (par exemple, avant les 60 secondes par défaut), appelez next_workflow également.
Sinon, attendez le rappel normal de l'authentification.

Cette approche minimise le temps d'attente, améliore l'expérience de l'utilisateur et garantit que votre backend passe toujours à l'étape correcte du flux de travail.

Scénarios de basculement

Dans cette section, nous énumérons tous les scénarios qui peuvent se produire lors d'une demande d'authentification silencieuse et nous conseillons des implémentations de basculement pour garantir une expérience optimale à l'utilisateur final.

Certains scénarios déclenchent un basculement immédiat vers le canal suivant, mais dans certains cas, le basculement n'est déclenché qu'après le délai d'attente par défaut de l'authentification silencieuse, qui est de 60 secondes. Le tableau ci-dessous résume les différents scénarios d'échec :

Scénario	Raison de l'échec	Code de défaillance	Réponse à l'échec	Basculement immédiat ?
1	Erreur d'authentification silencieuse	HTTP 409	`{ "title": "Silent Auth error", "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."}`	Oui
2	Erreur MSISDN	HTTP 409	`{ "title": "MSISDN Error", "detail": "Device MSISDN does not match."}`	Oui
3	Réseau non pris en charge	HTTP 412	`{ "title": "Network not supported", "detail": "Device number does not resolve to a supported Mobile Network Operator."}`	Oui
4	Erreur IP	HTTP 412	`{ "title": "IP Error", "detail": "IP Address does not resolve to a cellular device."}`	Oui
5	Erreurs du SDK iOS/Android	--	`sdk_no_data_connectivity`, `sdk_connection_error`, `sdk_redirect_error`, `sdk_error`	Non

Facturation par authentification silencieuse

Lorsqu'une demande d'authentification silencieuse est initiée, elle génère une entrée pour les frais de la plate-forme Verify et une ou deux entrées supplémentaires représentant l'utilisation de l'authentification silencieuse. L'entrée marquée comme INITIATED n'est jamais facturé. Au total, une seule demande d'authentification silencieuse peut avoir jusqu'à trois enregistrements associés.

Essais

Pour tester l'authentification silencieuse Verify, vous pouvez procéder comme suit :

Utilisation Numbers virtuels.
Autoriser l'énumération des numéros des réseaux pris en charge par l'intermédiaire de l'application Registre du réseau.

Si un client a besoin d'envoyer du trafic en direct, il doit s'enregistrer auprès de l'opérateur de téléphonie mobile via le site Web de l'opérateur. Registre du réseau.