Cada vez que agregaba verificación de identidad al registrarse en un servicio, el costo de enviar SMS se volvía una carga, así que invertimos el enfoque y creamos esta API de autenticación por celular.
En la verificación tradicional por SMS, el servicio envía un mensaje de verificación al usuario (MT, Mobile Terminated). Cuesta entre 9 y 50 wones por mensaje, más una tarifa base mensual, así que mientras más usuarios haya, mayor se vuelve el costo. Además, por temas de contrato y revisión, la integración puede tardar entre 1 y 2 semanas.
OCTOMO invirtió la dirección del flujo (MO, Mobile Originated). El usuario envía desde su propio celular un SMS con el código de verificación a un número designado, y el servicio solo consulta por API los mensajes recibidos. Como quien envía el mensaje es el usuario, el servicio no incurre en costos de envío, y como el mensaje fue enviado realmente desde ese dispositivo, también funciona como verificación de posesión.
El flujo recomendado es que, al presionar el botón de verificación, se abra la app de mensajes con el número de destino y el código ya rellenados, de modo que el usuario solo tenga que tocar el botón de enviar. (Como esto se maneja con un deeplink
sms:, hay una parte que debe implementarse en el frontend, pero en móvil este es el enfoque estándar). Como no hay que escribir manualmente el número ni el código, también baja la tasa de errores por captura incorrecta.En la práctica, la API tiene un solo endpoint.
POST /octomo/v1/public/message/exists
- Entrada: número de celular + código enviado por el usuario
- Salida: si se recibió o no, dentro de los últimos 5 minutos, un mensaje con ese código (
verified: true/false)El flujo de integración es simple: "tocar el botón → ejecución automática de la app de mensajes (número y código autocompletados) → el usuario envía → llamar a esta API y, si devuelve true, permitir el acceso". No requiere instalar una app aparte ni usar SDK; basta con hacer llamadas REST, y la documentación ya incluye ejemplos en Node/Java/Python.
También dejamos por escrito las limitaciones, siendo totalmente honestos.
- Aunque con el deeplink se elimina el esfuerzo de escribir los datos, sigue quedando un paso adicional: el usuario debe presionar una vez más el botón de enviar (es un trade-off frente a costo de envío 0 y una verificación de posesión más sólida).
- Como está basado en números de celular de Corea, no está orientado a usuarios del extranjero.
- Al usuario se le aplica la tarifa de SMS de su propio plan (si tiene plan ilimitado, en la práctica es gratis).
En particular, me interesa escuchar observaciones sobre UX o seguridad, por ejemplo: "¿con este flujo no aumentará mucho el abandono de usuarios?". Se agradece cualquier feedback.
16 comentarios
Oh, entonces es una especie de autenticación MO. Creo que sería aún mejor si se mencionara si este tipo de servicios, como la verificación de identidad o la verificación de posesión del teléfono móvil, cumplen con los requisitos legales de organismos clave relacionados, como la Comisión de Servicios Financieros, y si por ello tienen validez. ¡Les deseo mucho éxito!
¡Gracias por el apoyo!
¡Gracias por crear un gran servicio!
Veo que la verificación de si se recibió el mensaje está fijada actualmente a los últimos 5 minutos,
pero puede haber casos en los que se quiera manejar un período más corto o más largo que ese,
así que creo que también estaría bien permitir que el tiempo de verificación de recepción se pueda especificar dentro de los parámetros de la API.
¡Gracias por tu opinión! Revisaremos lo que mencionaste para mejorar y ofrecer un mejor servicio.
Como internamente desarrollamos y usamos esa función, hubo un momento en que pensé en operar también un SaaS de forma similar,
pero me parecía que esto podría tener algunos problemas legales.
Porque terminaría siendo una forma de venderles a los clientes el derecho a usar un número telefónico contratado a nombre de mi empresa,
y me hizo pensar: ¿no sería esto una violación de la Ley de Telecomunicaciones...?
Recuerdo que en la época de los feature phones se podía cambiar el número de origen como uno quisiera.
En ese entonces habría sido una tecnología sin efecto, pero es interesante que con el cambio de los tiempos se haya convertido en una tecnología aprovechable.
¡Gracias por tu interés!
Oh, qué buena idea
¡Gracias!
Al emitir el antiguo certificado público, se estaba usando una verificación en la que se respondía por SMS con un número específico, tal como mencionaste.
Como ya existe, aunque sea poco usada, una forma de verificación en la que el usuario envía el mensaje por sí mismo con este método, creo que no hace falta dar feedback sobre el concepto en sí.
Personalmente, prefiero este método antes que recibir un código de verificación e ingresarlo.
De todos modos, si se necesita verificación legal de identidad, habría que integrar PASS, así que lo dejo fuera de discusión...
Tengo entendido que la verificación de identidad y la verificación de posesión cumplen requisitos legales distintos, así que hay casos en los que necesariamente se debe usar verificación de identidad; estaría bien que se explicara mejor en qué casos basta con usar solo esta verificación de posesión.
¡Gracias por los comentarios!
Como mencionaste, la verificación de identidad y la verificación de posesión cumplen requisitos distintos,
así que agregaremos a la documentación una explicación más clara de en qué casos basta solo con la verificación de posesión.
¡Gracias por señalarlo con tanta precisión!
Oh, esto es algo que alguna vez había deseado que existiera, y parece que la API está súper fácil de usar...!
"el usuario envía por SMS el código de verificación a un número designado desde su propio celular"
Esta parte me confunde un poco, ¿la idea es indicarles que envíen el mensaje al número que proporciona OCTOMO?
Sí, así es. Solo deben indicar que envíen el código de verificación por mensaje de texto al número que proporciona OCTOMO.
En el entorno de app, les recomendamos implementar el uso del deep link
sms:para que, cuando el usuario presione el botón de verificación, la aplicación de mensajes se abra automáticamente.En el entorno web, actualmente ofrecemos el método de envío del mensaje de texto con el código de verificación y, adicionalmente, estamos desarrollando un método con código QR.
Estamos implementando que, cuando el usuario escanee el código QR, cambie automáticamente a la aplicación de mensajes.
¡Gracias!
Wow, está muy bueno.. lo voy a usar bien en algún side project jaja