Una sola plataforma: el porqué de unificar verificación, fraude y autenticación

Serie de Blogs de Ingeniería · La primera entrega de una nueva serie donde los ingenieros de Prelude revelan cómo se construye realmente el producto

En entrevista con Loïc Madiès, Ingeniero Principal de Backend en Prelude.

Antes de Prelude, trabajaba en el equipo de autenticación de un comercio electrónico en Francia. El fraude seguía siendo una parte importante del día a día.

La infraestructura técnica parecía razonable sobre el papel. Correo y contraseña, OTP para el doble factor y unos cuantos proveedores de inicio de sesión social. Por debajo: DataDome para el tráfico de bots, Vonage para el envío de OTP y una autenticación desarrollada de forma interna. Tres herramientas, un solo propósito —dar acceso al usuario— y ninguna de ellas se comunicaba con las demás. Al final, las cuentas fraudulentas se detectaban mediante modelos que analizaban patrones a posteriori, pero para entonces el atacante ya estaba dentro. 

No tenía visibilidad real de lo que ocurría en el momento. Ese vacío, sumado a la idea de que una plataforma diseñada para compartir señales entre esas piezas sonaba sumamente interesante, fue lo que me motivó a unirme a Prelude.

Tres herramientas, un propósito, cero contexto compartido

Esto es lo que hay que definir con precisión: cada una de esas tres herramientas hacía su trabajo de forma correcta, pero se perdía lo verdaderamente importante.

La autenticación por sí sola ya abarca mucho, pero no está pensada para detectar fraudes; se limita a validar si la contraseña es correcta, contar los intentos y aplicar límites de tasa de peticiones. Una herramienta antibot puede detectar que el volumen de intentos desde una IP o país concreto es algo elevado, pero no puede saber si es realmente sospechoso o tráfico normal sin los datos del número de teléfono que aporta la verificación.

Sin un contexto compartido, un sistema puede intuir que algo parece un bot y, aun así, dejarlo pasar como un inicio de sesión normal y sin alertas. 

Al conectar la información del lado antibot o de verificación con el flujo de autenticación, se pueden identificar patrones que ninguna de las partes detectaría por separado. Una contraseña de riesgo, un correo sospechoso o un pico inusual de intentos desde un país en un intervalo corto; ninguno de estos elementos es concluyente por sí solo.

Pero si los combinamos con el historial del dispositivo y del número de teléfono, la señal es mucho más clara. Y si el patrón de actualización de una sesión muestra una IP distinta en cada intento, tenemos un indicador sólido de un proxy residencial; algo que solo se detecta cuando analizas conjuntamente las señales de autenticación y de fraude.

Compartir ese contexto mejora la seguridad y beneficia directamente al usuario: evita reautenticaciones innecesarias porque el sistema ya sabe qué se ha verificado previamente.

No fue un parche posterior. Fue el plan desde el primer día

A veces se piensa que este tipo de unificación es un parche que se añade a posteriori, uniendo tres productos que nacieron separados. 

Pero no fue así. 

Compartir señales entre estos productos era la visión de la empresa desde el principio: delegar el registro y la confianza en un solo actor en lugar de varios, precisamente para que la información fluyera entre ellos.

El objetivo era permitir que los clientes se concentraran en su negocio en lugar de gestionar usuarios maliciosos por su cuenta. Un único actor que gestiona todo está en mejor posición para detectar más amenazas, con menos falsos positivos, de lo que tres sistemas desconectados podrían lograr jamás.

Yo empecé centrado en la autenticación, sin mirar tanto el fraude, simplemente porque había mucho por construir.

Una vez listas las funciones principales, me involucré en la verificación y el antifraude. Ahí fue donde ocurrió la sinergia para mí: los patrones que aprendí en el lado del fraude (bloqueo de tráfico abusivo de SMS, bots y robo de cuentas) influyeron directamente en cómo se comporta la autenticación, porque entonces la misma persona, y la misma señal, daban forma a ambos aspectos.

El ejemplo práctico más claro: tokens de actualización (Refresh Tokens)

Si tuviera que destacar un detalle técnico que ilustre esto mejor que cualquier argumento teórico, sería este.

En una infraestructura interna típica, si alguien roba un token (por ejemplo, interceptándolo en una red pública) y se solicita una actualización de token en ese instante, se podría reutilizar ese token robado. Esto era totalmente posible en mis anteriores empresas. 

Con esa experiencia en mente, decidimos que no fuera posible. Utilizamos claves privadas en el dispositivo del usuario para detectar si un token de actualización se está reutilizando desde un dispositivo diferente, gracias a una solución llamada DPoP. Esto aporta seguridad adicional, que reforzamos con un historial de huellas digitales del dispositivo para confirmar que se trata de un dispositivo distinto intentando usar la misma sesión.

Es un problema real porque, al desarrollar de forma interna, te centras en el inicio de sesión y olvidas lo que viene después; los usuarios actualizan su sesión muchísimo más de lo que inician sesión de cero. 

Este proceso se vuelve más seguro precisamente porque comparte señales con el área de fraude: en el frontend ya recopilamos suficiente información del dispositivo, lo que facilita la detección de estos patrones.

La verdad sin rodeos: el riesgo de caída del servicio

La única desventaja real, y no sería honesto ocultarla, es que centralizar implica que una caída del servicio puede tumbar los tres servicios a la vez, ya que todos comparten la misma ruta crítica.

No voy a fingir que nuestro enfoque es una victoria absoluta en este aspecto, porque no lo es. Si gestionas tres proveedores independientes, cada uno sigue siendo su propia ruta crítica para su función; por tanto, si falla uno solo, el usuario tampoco podrá iniciar sesión, que es el mismo resultado que si cae nuestro sistema integrado. 

La diferencia real es el número de puntos de fallo: una sola superficie de caída que detiene todo junto, frente a tres superficies independientes, cada una capaz de provocar el mismo fallo por separado. Es un equilibrio de riesgos, y prefiero explicarlo con claridad antes que venderlo como algo que no es.

El verdadero reto: la migración

Si existe un obstáculo real para los clientes potenciales, es la migración, y conviene detallar por qué.

Cambiar un proveedor que solo hace verificación es sumamente sencillo: se reemplaza una llamada a la API (o tal vez dos) y listo. 

La autenticación es un reto totalmente distinto porque requiere datos: quién está registrado y cómo (incluyendo inicios de sesión de Google que deben trasladarse). Técnicamente es una sola acción, pero requiere varias semanas de ejecución y, como no parece una función nueva (como lo sería activar un nuevo método de pago), los equipos de producto no suelen priorizarla.

Todos los proveedores de autenticación se enfrentan exactamente a este problema, no solo Prelude.

Lo que requiere un cuidado extremo es no perder usuarios en el proceso. Existe un temor real en ambas partes a que un error de migración cierre las sesiones de los usuarios o que un cambio de contraseña o teléfono deje a alguien fuera de su cuenta. Por eso, la migración a Prelude también cubre las sesiones existentes, no solo las credenciales, garantizando que quienes ya han iniciado sesión permanezcan conectados durante la transición.

La simplicidad como el verdadero elemento diferenciador

Lo que realmente nos diferencia de los competidores que también hablan de unificar estas piezas se reduce a dos cosas: ir un paso por delante en el ámbito del fraude (especialmente en la verificación por SMS) y una decisión deliberada sobre cuánto control le quitamos al cliente.  

La mayoría de los proveedores de acceso te redirigen a una página externa de inicio de sesión, lo cual resulta molesto en dispositivos móviles; una web abierta dentro de una app nativa rara vez ofrece una buena experiencia. 

La apuesta de Prelude Auth fue no construir esa interfaz gráfica: gestionamos la seguridad y la lógica del backend, exponemos el inicio de sesión como un método que el cliente invoca directamente y dejamos que diseñen su propia interfaz sobre él. Es una elección consciente frente a soluciones cerradas y basadas en plantillas.

Esa misma filosofía se refleja en los precios y el alcance. El objetivo es evitar cobrar por funcionalidad, de modo que las nuevas capacidades no incrementen la factura del cliente de forma silenciosa, como ocurre con proveedores que empaquetan funciones que nadie ha pedido. 

Nuestra visión es desarrollar las funciones que el 90% de las empresas necesitan, incluso si eso significa no encajar con el 10% restante. Lo importante no es cuántos métodos de inicio de sesión ofreces; ya existen estándares documentados de sobra, y gran parte de esa documentación puede procesarla una IA para programarlos por ti.

El núcleo de la autenticación es el fraude. Ahí es donde somos realmente fuertes.

Dos patrones de fraude específicos que detectamos

Vale la pena mencionar dos ejemplos concretos, ya que son lo suficientemente específicos como para comprobarse en la práctica.

Ataques de diccionario basados en datos filtrados. Una parte significativa de los ataques de credenciales no son aleatorios. Se construyen con información ya filtrada: direcciones, nombres de familiares o de hijos. Un atacante puede definir una lista corta de contraseñas probables y realizar unos pocos intentos espaciados en el tiempo para evitar los límites de tasa estándar (por ejemplo, un par de intentos cada diez minutos durante varios días, en lugar de una ráfaga que activaría las alarmas). Ya conocía este patrón antes de Prelude; es uno de los problemas para los que Watch está diseñado específicamente, utilizando señales compartidas en lugar de un simple recuento de intentos.

Proxies residenciales a gran escala. Los bots intentan camuflarse rotando por direcciones IP residenciales en lugar de usar IPs sospechosas de centros de datos. El análisis de red puede identificar este patrón, pero solo si analiza un volumen suficiente de datos: un único intento de acceso lento y cuidadoso cada veinte minutos no parece inusual por sí solo. Lo que lo delata es el patrón global a gran escala y el comportamiento posterior en el sitio web. Un sistema que solo vigile la autenticación de forma aislada nunca lo detectará.

La conclusión

Nuestra apuesta es que la verificación, la autenticación y la prevención del fraude compartiendo señales —como un único paquete en lugar de tres soluciones conectadas a la fuerza— representan una solución estructuralmente diferente y mucho más potente que unir piezas sueltas a posteriori.

Lo que he aprendido trabajando en esto, tras haber desarrollado la autenticación interna para una sola empresa y luego construirla como una plataforma compartida para muchas, es que son disciplinas completamente distintas. 

El acceso a los datos de múltiples clientes, en lugar de limitarse a la perspectiva de un solo producto, es la clave: un patrón global se detecta en toda la base de clientes de la plataforma compartida mucho antes de que afecte a un cliente individual. 

Cuando construyes en casa, solo ves tu propia parcela. Ese es exactamente el vacío con el que empecé este texto y que viví en primera persona años atrás, antes de poder ponerle nombre.

¿Quieres ver cómo funciona esto en tu infraestructura?

Si todo esto (especialmente el detalle de los tokens de actualización) te suena a un problema que actualmente intentas resolver con tres proveedores distintos, habla con el equipo de Auth sobre tu caso particular.

Loïc Madiès es ingeniero en Prelude y trabaja en el equipo de Auth. Llegó a Prelude desde Leboncoin, donde se especializó en gestión de sesiones y sistemas antifraude, aportando esa experiencia para que el producto de autenticación de Prelude comparta señales entre sesiones de forma eficaz hoy en día. Estudió ingeniería en Polytech Lyon.