Diseño de estado para OTP en Node.js: control en la app, no en la API
Un análisis técnico propone mantener la autoridad de la verificación en el backend y tratar la API de SMS como un simple transporte.
No existe una API de SMS OTP universalmente superior para aplicaciones transfronterizas. El debate real no es qué proveedor contratar, sino dónde reside la autoridad sobre el estado de la sesión. Un artículo publicado en Dev.to argumenta que la aplicación debe poseer una máquina de estados atómica para la gestión del OTP, mientras que el proveedor externo se limita a transportar mensajes y reportar resultados de entrega.
La autoridad en el backend
El riesgo principal de delegar la lógica de verificación en el proveedor de SMS es perder el control sobre transiciones críticas como el reenvío o la cancelación. Cancelar un código no hace que desaparezca del teléfono del usuario; solo garantiza que el servidor lo rechace. Del mismo modo, reenviar un OTP no es simplemente hacer otra llamada de envío: define si el código anterior sigue siendo válido y cómo se manejan las condiciones de carrera cuando dos pestañas del navegador actúan simultáneamente.
Para un desarrollador de Node.js, esto implica diseñar un contrato estricto donde el desafío (challenge) tiene un identificador opaco, una suma de verificación con sal, una fecha de expiración y un contador de intentos. El proveedor recibe el mensaje renderizado y un identificador de correlación, pero nunca tiene la autoridad para reabrir un desafío que ya ha alcanzado un estado terminal como verificado, cancelado o bloqueado.
El texto sugiere exponer comandos en lugar de campos de estado modificables directamente: crear, verificar, reenviar y cancelar. Cada comando debe comprobar la versión almacenada y comprometer exactamente una transición. En la implementación, se debe usar un mecanismo de comparación e intercambio (compare-and-swap) sobre la versión del objeto para evitar que dos procesos escriban la misma generación de código.
Manejo de fallos y concurrencia
Los problemas surgen cuando se tratan los timeouts y las entregas tardías. Si una solicitud de envío expira, no se sabe si el mensaje ya está en camino por la red de operadores. Reintentar a ciegas puede generar SMS duplicados. La recomendación técnica es reutilizar la misma clave de idempotencia, registrar una nueva generación de envío solo una vez y tratar los recibos tarde como telemetría, no como permisos para cambiar el estado de inicio de sesión.
También se abordan las políticas geográficas. El tráfico de EE. UU. y la UE tiene diferentes restricciones de consentimiento, retención y envío. En lugar de condicionales dispersos basados en la región, se propone manejar la política por país con controles canary, aprobados por revisión de cumplimiento antes del despliegue. Los registros deben contener los identificadores del desafío y del mensaje del proveedor, pero nunca el OTP en sí mismo, para evitar fugas de información en las auditorías.
