- L'utilisateur demande un codeConnexion, paiement ou inscription
- Votre application appelle l’API de vérificationUne requête par code
- BroadNet délivre le codeVia le meilleur canal disponibleSolution de secours en cas de non-délivranceSMSWhatsAppVoix
- L'utilisateur saisit le codeVérification par rapport au code émis
- VérifiéAccès accordé
Ce qu'est un OTP
Un mot de passe à usage unique (OTP) est un code valable pour une seule connexion ou transaction. C'est le second facteur de l'authentification à deux facteurs : quelque chose que l'utilisateur reçoit, prouvant le contrôle d'un numéro de téléphone ou d'un authentificateur, en plus d'un mot de passe qu'il connaît.
Les OTP sont les messages les plus critiques que la plupart des entreprises envoient. Un code en retard ou manquant se traduit par une connexion échouée, une inscription abandonnée, ou une vente perdue ; le trafic OTP est donc traité comme une classe distincte, avec des budgets de latence serrés et des fenêtres de validité courtes.
La vérification de numéro est la tâche connexe consistant à prouver qu'un utilisateur contrôle bien un numéro de téléphone donné — le fondement de la sécurité des comptes, de la réduction de la fraude, et de données de contact propres.
Comment les codes sont générés : HOTP et TOTP
HOTP (RFC 4226) génère un code à partir d'un secret partagé et d'un compteur via HMAC. Chaque utilisation incrémente le compteur, si bien que les codes ne se répètent pas. C'est le fondement des jetons basés sur des événements.
TOTP (RFC 6238) remplace le compteur par le temps courant divisé en étapes fixes (le plus souvent de 30 secondes), de sorte que les deux parties dérivent le même code à partir du même secret et de la même horloge. C'est ce qu'utilisent les applications d'authentification, et cela fonctionne hors ligne car aucun message n'a besoin d'être livré.
Pour les OTP livrés par SMS, le code est généralement une valeur numérique aléatoire courte générée côté serveur, liée à la session ou à l'appareil, et expirée après la première utilisation ou un délai. Six chiffres est la valeur par défaut courante, qui équilibre facilité d'usage et résistance à la devinette.
Canaux de livraison et repli
Le SMS est le canal OTP par défaut en raison de sa portée universelle, mais ce n'est pas le seul. L'OTP vocal lit le code à voix haute et aide dans les marchés où la délivrabilité SMS est médiocre, ou pour l'accessibilité. WhatsApp et le RCS peuvent livrer des codes de façon riche là où l'utilisateur y est joignable.
La vérification par flash call est une alternative économique : la plateforme passe un appel que l'application détecte et rejette automatiquement, vérifiant le numéro à partir des derniers chiffres du numéro appelant, sans que l'utilisateur ait à répondre. Elle supprime entièrement le coût du SMS et la saisie manuelle du code.
Une cascade de canaux combine tout cela : essayer un premier canal, et si la livraison n'est pas confirmée en quelques secondes, escalader vers le suivant. La cascade doit être délimitée dans le temps et éviter d'envoyer le même code sur deux canaux à la fois, ce qui double le coût et l'exposition à la fraude.
Autofill, conception du message et latence
Les messages OTP bien conçus convertissent mieux. Gardez le corps minimal, à la marque, et cohérent afin qu'il passe les filtres de contenu, et prenez en charge les conventions d'autofill de la plateforme — comme le format de code à usage unique lié à l'origine sur la dernière ligne — afin que le code soit saisi automatiquement.
Ne placez jamais le code dans un lien cliquable qui pourrait être hameçonné ; gardez-le uniquement copiable ou saisissable. Localisez le texte environnant tout en gardant le code et le jeton de marque stables afin que l'autofill et la reconnaissance par l'utilisateur continuent de fonctionner.
Mesurez la latence de bout en bout jusqu'au téléphone (soumission jusqu'au DLR), pas seulement le temps de soumission-acceptation, et fixez une courte période de validité afin qu'un code retardé expire plutôt que d'arriver périmé. Déclenchez le repli sur un DLR manquant dans votre budget de latence, pas seulement sur un échec explicite.
Se défendre contre l'AIT / le SMS pumping
Le trafic artificiellement gonflé (AIT), aussi appelé SMS pumping, est une fraude où des attaquants déclenchent des envois d'OTP d'apparence légitime vers des numéros qu'ils contrôlent, gonflant votre facture sans aucun utilisateur réel derrière eux. C'est le domaine à défendre offrant le meilleur retour sur investissement pour la plupart des expéditeurs.
Les contrôles essentiels sont les limites de débit — par numéro de téléphone, par IP, par empreinte d'appareil, par compte — ainsi qu'un plafond sur les renvois par session et une friction ajoutée (un challenge ou un CAPTCHA) lorsque la vélocité s'emballe depuis une source.
Surveillez la conversion par destination : le trafic pompé montre un flot de requêtes avec une saisie de code proche de zéro, et une brusque poussée vers une plage de pays inhabituelle en est la signature classique. Valider les numéros avec un lookup HLR / d'intelligence numérique avant l'envoi rejette d'emblée les numéros invalides et à risque.
- Les OTP sont une classe de trafic distincte et sensible à la latence ; HOTP est fondé sur un compteur et TOTP (RFC 6238) sur le temps.
- Les canaux incluent SMS, voix, WhatsApp/RCS et flash call ; combinez-les dans une cascade de repli délimitée dans le temps.
- Prenez en charge l'autofill, gardez les codes hors des liens, utilisez une validité courte, et mesurez la latence de livraison de bout en bout.
- L'AIT / le SMS pumping se défend par des limites de débit, des plafonds de renvoi, un suivi de la conversion, et des contrôles de numéro avant envoi.