Voici une API de vérification par téléphone mobile conçue en inversant le sens habituel, car le coût d’envoi des SMS devenait lourd à chaque intégration d’une vérification d’identité lors de l’inscription à un service.
Dans la vérification SMS classique, c’est le service qui envoie un SMS de vérification à l’utilisateur (MT, Mobile Terminated). Avec un coût de 9 à 50 wons par message, auquel s’ajoutent des frais mensuels fixes, la facture augmente à mesure que le nombre d’utilisateurs croît, et l’intégration peut aussi prendre 1 à 2 semaines à cause des contrats et des procédures de validation.
OCTOMO a inversé cette logique (MO, Mobile Originated). L’utilisateur envoie lui-même par SMS un code de vérification à un numéro désigné depuis son propre téléphone, et le service se contente de vérifier via l’API si le message reçu existe. Comme c’est l’utilisateur qui envoie le SMS, le service n’a aucun coût d’envoi, et le fait que le message ait réellement été envoyé depuis cet appareil constitue une preuve de possession.
Le flux recommandé est le suivant : lorsqu’on appuie sur le bouton de vérification, l’application SMS s’ouvre avec le numéro du destinataire et le code déjà préremplis, et l’utilisateur n’a plus qu’à appuyer sur le bouton d’envoi. (
sms:est géré via un deep link, donc cette partie doit être implémentée côté front, mais sur mobile c’est la méthode standard.) Comme il n’y a ni saisie manuelle du numéro ni risque de faute de frappe sur le code, le taux d’échec diminue lui aussi.L’API se résume en pratique à un seul endpoint.
POST /octomo/v1/public/message/exists
- Entrée : numéro de téléphone mobile + code envoyé par l’utilisateur
- Sortie : indication de la réception ou non, dans les 5 dernières minutes, d’un SMS contenant ce code (
verified: true/false)Le flux d’intégration est simple : « tap sur le bouton → lancement automatique de l’app SMS (numéro et code saisis automatiquement) → envoi par l’utilisateur → appel de cette API, puis validation si la réponse vaut true ». Aucun besoin d’installer une application distincte ni de SDK : il suffit d’appeler l’API REST. Des exemples Node/Java/Python sont inclus dans la documentation.
Voici aussi les limites, en toute transparence.
- Le deep link supprime l’effort de saisie, mais l’utilisateur doit toujours appuyer une fois de plus sur le bouton d’envoi (un compromis en échange d’un coût d’envoi nul et d’une preuve de possession renforcée).
- Comme le système repose sur des numéros de mobile coréens, il ne cible pas les utilisateurs à l’étranger.
- Les frais de SMS de l’utilisateur restent ceux de son propre forfait (ce qui est pratiquement gratuit avec un forfait illimité).
J’aimerais particulièrement recueillir des retours sur les éventuelles inquiétudes UX du type « ce flux ne risque-t-il pas d’augmenter fortement l’abandon utilisateur ? » ainsi que sur les remarques liées à la sécurité. Tous les retours sont bienvenus.
16 commentaires
Oh, c’est donc une sorte de vérification MO. Je pense qu’il serait encore mieux de préciser si des services comme cette vérification d’identité ou cette vérification de détention du téléphone ont une valeur juridique en satisfaisant aux exigences légales des principaux organismes concernés, comme le Service de supervision financière. Je vous soutiens !
Merci pour votre soutien !
Merci d’avoir créé un si bon service !
La vérification de la réception des SMS semble actuellement fixée aux 5 dernières minutes,
mais il peut y avoir des cas où l’on souhaiterait une durée plus courte ou plus longue.
Je pense donc qu’il pourrait être intéressant de permettre de définir, via un paramètre de l’API, le délai de vérification de la réception.
Merci pour votre retour ! Nous allons examiner le point que vous avez mentionné et améliorer le service pour le rendre encore meilleur !
Comme j’avais développé et utilisé cette fonctionnalité en interne, je m’étais déjà demandé s’il ne fallait pas aussi lancer un SaaS de type similaire.
Mais je me disais qu’il pouvait y avoir des questions juridiques.
Au final, cela revient à vendre aux clients le droit d’utiliser un numéro de téléphone contracté au nom de mon entreprise,
et je me suis demandé si cela ne risquait pas de constituer une violation de la loi sur les télécommunications...
Ça me rappelle l’époque des téléphones à touches, quand on pouvait changer librement le numéro de l’appelant.
À l’époque, ça aurait été une technologie sans effet, mais c’est intéressant de voir qu’avec le changement d’époque, c’est devenu une technologie exploitable.
Merci de votre intérêt !
Oh, bonne idée
Merci !
Lors de la délivrance des anciens certificats officiels, on utilisait bien une authentification sous la forme d’une réponse par SMS avec un numéro précis, comme vous l’avez indiqué.
Il existe déjà, même si c’est marginal, des méthodes de vérification où l’utilisateur envoie lui-même le message selon ce principe, donc je pense qu’un retour sur le concept n’est pas particulièrement nécessaire.
À titre personnel, je préfère cette approche à celle où l’on reçoit un code de vérification puis on le saisit.
De toute façon, lorsqu’une vérification d’identité légale est nécessaire, il faudra sans doute intégrer PASS, donc je laisse ça de côté...
Je crois comprendre que la vérification d’identité et la vérification de possession ne satisfont pas aux mêmes exigences légales, et qu’il existe donc des cas où il faut impérativement utiliser la vérification d’identité ; ce serait bien d’expliquer plus clairement dans quels cas cette seule vérification de possession peut suffire.
Merci pour votre retour !
Comme vous l’avez souligné, les exigences remplies par la vérification d’identité et la vérification de possession sont différentes,
nous allons donc préciser davantage dans la documentation dans quels cas la seule vérification de possession est suffisante, et l’ajouter.
Merci d’avoir pointé cela avec précision !
Oh, c’est le genre de truc que j’aurais aimé voir exister au moins une fois, et l’API a l’air vraiment très simple à utiliser... !
« L’utilisateur envoie le code de vérification par SMS au numéro indiqué depuis son propre téléphone portable »
Cette partie est un peu ambiguë, mais il s’agit bien de guider l’utilisateur pour qu’il envoie un SMS au numéro fourni par OCTOMO, n’est-ce pas ?
Oui, c’est bien ça ! Il suffit d’indiquer aux utilisateurs d’envoyer le code de vérification par SMS au numéro fourni par OCTOMO.
Dans un environnement applicatif, nous vous recommandons d’utiliser un deep link
sms:afin que l’application de messagerie s’ouvre automatiquement lorsque l’utilisateur appuie sur le bouton de vérification !Dans un environnement web, nous proposons actuellement l’envoi du SMS avec le code de vérification, et nous développons également une méthode par QR code.
Lorsque l’utilisateur scanne le QR code, nous sommes en train de mettre en place une transition automatique vers l’application de messagerie !
Merci !
Waouh, c’est vraiment top… je vais bien l’utiliser pour mes projets perso haha