Minería de procesos de autenticación: la próxima disciplina de CIAM

1. Introducción#

Las passkeys están impulsando a CIAM hacia adelante. Los mejores equipos están comenzando a instrumentar el viaje de inicio de sesión de extremo a extremo, a clasificar errores que nunca antes habían registrado y a observar la telemetría del lado del cliente por primera vez. La gran mayoría de los equipos de identidad aún no han llegado a ese punto: no existe una verdadera capa de observabilidad de autenticación, no hay un gráfico de eventos por sesión, ni datos de la ceremonia del lado del cliente. El intento, el éxito y el fracaso del lado del servidor siguen siendo el panorama completo.

La minería de procesos de autenticación es el siguiente paso lógico, pero solo una vez que existan los datos de eventos subyacentes. Sin la capa de observabilidad, no hay nada que minar. Con ella, se abre una nueva disciplina. Se inspira directamente en la minería de procesos de negocio, que convirtió los registros de eventos ERP sin procesar en flujos de trabajo optimizados en la década de 2010. Aplicada a la identidad, compara el viaje de inicio de sesión diseñado con el viaje real, expone las rutas de desviación y luego cierra la brecha con reglas de supresión o autenticación step-up detalladas, o cambios de UX que se miden de extremo a extremo.

Este artículo replantea lo que los equipos de CIAM deberían estar construyendo sobre la capa de observabilidad de autenticación.

1.1 Preguntas que responde este artículo#

En este artículo abordamos las siguientes preguntas:

1. ¿Qué hizo la minería de procesos por BPM y cuál es su paralelo directo en la autenticación?
2. ¿Por qué las implementaciones de passkeys sacaron a la luz esta brecha y por qué los registros de autenticación nunca fueron suficientes por sí solos?
3. ¿Cómo es realmente un modelo de eventos de minería de procesos de autenticación de extremo a extremo?
4. ¿Cómo se conecta la minería de procesos con la autenticación step-up y la autorización detalladas?
5. ¿Qué significa esto para el panorama de proveedores de CIAM y para los equipos de identidad que ya cuentan con un IDP?

2. Lo que la minería de procesos hizo por BPM#

2.1 De registros de eventos a procesos optimizados#

La minería de procesos de negocio surgió al comprender que cada sistema ERP, CRM o de tickets escribe registros de eventos que, al reconstruirse, revelan el flujo de trabajo real, no el que está en la wiki. Una orden de compra que debía pasar por tres aprobadores terminaba eludiendo a dos de ellos el 40% de las veces. Un flujo de reclamos documentado como una línea recta volvía sobre sí mismo cinco veces en el 18% de los casos. Las herramientas de minería de procesos, como las popularizadas por Celonis, reconstruyeron esos gráficos a partir de eventos con marcas de tiempo y permitieron a los operadores hacer una nueva pregunta: ¿dónde diverge el proceso real del proceso diseñado y cuánto cuesta esa divergencia?

2.2 Paralelo en la autenticación#

La autenticación tiene la misma estructura. Cada inicio de sesión es una secuencia de eventos con marca de tiempo: se carga la página, se ingresa el identificador, se selecciona el desafío, se solicita la biometría, se devuelve la aserción. El paralelo estructural es exacto. La diferencia práctica radica en que, a diferencia de los sistemas ERP o CRM, estos datos de eventos aún no viven en los registros de su IDP, al menos no en la forma granular que requiere la minería de procesos. Los IDP registran los resultados del inicio de sesión y el método utilizado. No registran la ceremonia subyacente del lado del cliente: la invocación de Conditional UI, las solicitudes biométricas, la selección del administrador de credenciales, el abandono silencioso antes de que una solicitud llegue al servidor. Esa capa previa a la aserción debe ser instrumentada en la capa del SDK del frontend y reensamblada en un gráfico por sesión antes de que la minería de procesos pueda operar sobre ella.

Una vez que los datos están ahí, se aplican las mismas técnicas: el viaje diseñado de la passkey frente al viaje real de la passkey, el flujo de recuperación diseñado frente al flujo de recuperación real, el step-up diseñado frente al step-up real. La disciplina académica en torno a este trabajo está madurando. Un punto de partida útil es el Process Mining Manifesto del IEEE Task Force on Process Mining, que establece la verificación de conformidad, el análisis de variantes y la mejora como las tres técnicas centrales. Cada una se asigna directamente a la autenticación.

3. Por qué las implementaciones de passkeys revelaron la brecha#

3.1 Las passkeys obligan a los equipos a replantearse el registro en el frontend#

La autenticación clásica por contraseña registraba tres cosas en el lado del servidor: intento, éxito, fracaso. Eso es suficiente para administrar un sistema de contraseñas, porque el modo de fallo es simple: el usuario ingresó mal una cadena y el siguiente intento funcionó o no. Con las passkeys, los momentos críticos pasan al frontend: la activación de Conditional UI, el navegador decidiendo si mostrar un aviso, el administrador de credenciales ofreciendo una opción, el desafío biométrico que tiene éxito o se descarta. Todo esto ocurre en el dispositivo del consumidor, antes de que la aserción llegue al backend.

Ese cambio es la razón por la que muchos equipos ahora están replanteando cómo registran el comportamiento del lado del cliente. Sin instrumentación en el frontend, no pueden ver por qué los usuarios abandonan, qué pasos dan antes de iniciar sesión o qué sucedió realmente cuando un intento de inicio de sesión no se completó. Los registros del servidor solo muestran la ausencia, no la causa. Consulta nuestro análisis profundo sobre observabilidad de autenticación para ver la taxonomía completa de eventos.

3.2 Brecha entre el viaje diseñado y el viaje real#

Una vez que los equipos obtuvieron los eventos del lado del cliente, pudieron ver algo nuevo: el viaje diseñado para la passkey (llegar al inicio de sesión, ver el botón de passkey, tocar, autenticar, terminar) era utilizado quizás por un 30% de los usuarios elegibles. El otro 70% se desviaba hacia campos de contraseña, inicio de sesión social, enlaces mágicos o abandonaba por completo. Ese es un problema de minería de procesos, no de registro. Ninguna cantidad de códigos de error adicionales de WebAuthn habría cerrado la brecha por sí sola.

3.3 Por qué los registros de autenticación nunca fueron suficientes#

Los registros de autenticación por sí solos nos informan sobre los resultados. No revelan las trayectorias. Una tasa de éxito de inicio de sesión del 92% en todos los métodos puede ocultar una tasa de abandono del 40% en la ruta de las passkeys y del 15% en la ruta de las contraseñas, pareciendo estar "bien" en promedio. La minería de procesos rechaza ese promedio. Insiste en observar cada variante por separado y luego clasificar las variantes por frecuencia, costo y tasa de fallo.

4. Cómo es realmente la minería de procesos de autenticación#

4.1 Modelo de eventos: procesos, eventos y clasificación de resultados#

La unidad de análisis no es un evento único, sino un proceso: un intento completo de inicio de sesión o de adición de credencial en el dispositivo del consumidor, desde el momento en que se carga la interfaz de autenticación hasta el momento en que la sesión se completa o se abandona. Cada proceso contiene un flujo de eventos granulares, lleva metadatos de identificación y finaliza con una clasificación de resultados más rica que el simple "éxito o fracaso" binario.

Metadatos del proceso. Cada proceso tiene un ID de proceso y una marca de tiempo. Está vinculado a una aplicación, un SO, un navegador y una marca de dispositivo. Se etiqueta con una categoría de visitante (usuario real, probador manual, probador automático, aún no clasificado) de manera que el tráfico automatizado y de bots se pueda aislar antes de calcular cualquier métrica. También incluye un puntaje de proceso y un recuento de eventos, que son las dos señales más simples para medir "qué tan compleja fue esta sesión en particular".

Inicio de sesión. Cada proceso registra cómo se inició el flujo. Los principales tipos de inicio son text-field (el usuario ingresó su identificador), one-tap (se reutilizó un identificador almacenado) y cui (Conditional UI mostró una credencial sin un clic explícito en un botón). El inicio es una dimensión, no una métrica: la misma implementación puede verse muy diferente en la cohorte cui que en la cohorte text-field, y promediar ambas oculta exactamente el comportamiento que la minería de procesos busca revelar.

Clasificación de resultados. En lugar de "éxito" o "fracaso", el resultado corresponde a una de varias clases que se asignan a un comportamiento distinto. Un ejemplo para passkeys es el siguiente:

• completed - la ceremonia finalizó y el usuario está autenticado.
• filtered-explicit-abort - el usuario vio un aviso y lo canceló explícitamente.
• filtered-implicit-abort - el usuario se alejó o se agotó el tiempo de espera sin decidir.
• filtered-passkey-intel - la capa de inteligencia del lado del cliente suprimió la ruta de la passkey a propósito, generalmente porque se sabe que la combinación de dispositivo/SO está defectuosa.
• filtered-no-start - el flujo nunca avanzó más allá del paso inicial.
• not-loaded - la interfaz de autenticación nunca terminó de cargarse.

La ceremonia de adición (creación de credenciales) tiene una clasificación paralela, incluido un caso completed-exclude-credentials para cuando un usuario ya tiene una credencial.

Capas de embudo e inventario. Por encima de los procesos, importan dos capas agregadas. Una capa de embudo agrupa los procesos a lo largo del tiempo por resultado, inicio, estado de finalización, SO y aplicación, tanto para el inicio de sesión como para la adición. Una capa de inventario de credenciales agrupa las passkeys existentes por estado de sincronización (sincronizadas frente a no sincronizadas), transporte (internal, hybrid, usb, nfc, ble, smart-card), autenticador (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), SO y navegador. Sin la capa de inventario es imposible saber si una variante de desviación dada se concentra en un administrador de credenciales o estado de sincronización específico.

Esta es la forma mínima que hace manejable la minería de procesos. Cada evento conlleva suficientes metadatos para ser agrupado, filtrado y clasificado. Cada proceso puede ser rastreado individualmente, lo que posibilita los ejemplos a continuación.

4.2 Ruta feliz frente a análisis de desviaciones#

Una vez que los eventos se almacenan como un gráfico dirigido por sesión, se puede formular la pregunta de minería de procesos: ¿qué porcentaje de las sesiones siguen la ruta feliz y, para las que no lo hacen, cuáles son las cinco principales variantes de desviación clasificadas por frecuencia? En nuestros datos analíticos, las cinco variantes principales suelen representar el 85% de todas las desviaciones. Solucionar dos de ellas generalmente mejora los números más que cualquier prueba A/B en la ruta feliz.

4.3 Detección de la deriva de cohortes#

Las variantes cambian. Una actualización del navegador, un lanzamiento del SO o un cambio en el administrador de credenciales pueden hacer que una variante previamente menor de repente se vuelva dominante. La detección de la deriva de cohortes es la disciplina de observar la distribución de variantes por cohorte de dispositivo/SO/navegador a lo largo del tiempo, en lugar de mirar solo la tasa de éxito agregada. Así es como los equipos capturan regresiones silenciosas en horas en lugar de en trimestres.

5. De la minería de procesos al Step-up detallado#

5.1 Por qué se ha subutilizado el Step-up#

La autenticación step-up existe desde hace más de una década. Se ha subutilizado porque la mayoría de los equipos hacen el step-up de la misma manera sin importar el riesgo: forzar un OTP en cada transacción por encima de un límite. Esa es una regla contundente, no una decisión basada en riesgos. Crea fricción en el 95% de las transacciones legítimas de alto valor para detener el 5% que son sospechosas.

5.2 Viajes con puntuación de riesgo#

Con los datos de minería de procesos, se puede calificar una sesión de manera continua. Reputación del dispositivo, tasa de éxito base de la cohorte, anomalías horarias, desviación de la ruta histórica del usuario, identidad del administrador de credenciales, reputación de IP. Luego, la puntuación de riesgo impulsa una decisión detallada de step-up: requerir un segundo factor solo cuando la puntuación de riesgo de la sesión supera el límite del valor de la transacción. Las sesiones de bajo riesgo para transacciones de alto valor pasan. Las sesiones de alto riesgo para transacciones de bajo valor requieren autenticación step-up.

6. Lo que esto significa para el panorama de proveedores de CIAM#

6.1 El diseño del viaje como una disciplina especializada#

Históricamente, la industria de la identidad ha incluido el diseño del viaje dentro del IDP. Los motores de orquestación dentro de Okta, Ping, ForgeRock, Auth0 y otros permiten configurar flujos. Lo que no hacen bien es observarlos. Ese desajuste es lo que abre un espacio para una capa de análisis especializada.

6.2 Por qué ningún IDP incluirá esto de forma nativa#

Los proveedores de IDP optimizan para el plano de control: quién puede iniciar sesión, con qué credencial, bajo qué política. La minería de procesos es una disciplina del plano de datos: cada evento, a escala, normalizado en todas las combinaciones de SO/navegador/administrador de credenciales. El volumen de eventos, la cardinalidad y las líneas de base entre clientes actúan en contra de una compilación de IDP nativa. Consulta las notas de campo en nuestra guía de comprar frente a construir passkeys para el mismo patrón aplicado a la capa del SDK.

6.3 La capa de análisis como la nueva categoría#

Lo que surge es una capa delgada de análisis y adopción que se ubica por encima del IDP, ingiere eventos del frontend, los normaliza con respecto a las líneas de base de implementación cruzada y retroalimenta las decisiones de orquestación. No reemplaza al IDP. Hace que el IDP sea medible.

7. Cómo Corbado ayuda con la minería de procesos de autenticación#

Corbado proporciona la capa de medición y adopción que se sitúa por encima de los IDP existentes. Se integra con Okta, Auth0, Ory, ForgeRock y pilas personalizadas sin reemplazarlas. Lo que agrega es específicamente la capacidad de minería de procesos:

• Taxonomía de eventos de extremo a extremo. El SDK del lado del cliente captura la ceremonia completa desde la carga de la página hasta la aserción, incluidos los eventos previos al identificador, la invocación de Conditional UI y la selección del administrador de credenciales.
• Análisis de variantes listo para usar. La plataforma reconstruye los gráficos de los viajes por cohorte y clasifica las variantes de desviación por frecuencia, oportunidad de recuperación y costo.
• Alertas de deriva de cohorte. Cuando la distribución de una variante cambia para un SO, navegador o administrador de credenciales específico, la plataforma lo señala antes de que se convierta en un problema del día 2.
• Líneas de base de implementaciones cruzadas. Debido a que Corbado agrega datos anonimizados en todos los entornos de clientes, los nuevos errores o regresiones que surgen en una implementación se clasifican y documentan antes de que lleguen a la tuya. Conoce por qué elegir Corbado para ver el enfoque completo.
• Retroalimentación en la orquestación. Las decisiones de step-up basadas en riesgos y las reglas de supresión se pueden devolver al IDP o manejarse en la capa de adopción, incluidos los interruptores de apagado dinámicos y los empujones específicos por cohorte.

8. Conclusión#

Las passkeys no eran el destino final. Fueron la cuña de instrumentación que está obligando a la primera ola de equipos de CIAM a registrar eventos del lado del cliente. Una vez que existe esa capa de observabilidad, una nueva disciplina se sitúa por encima: la minería de procesos de autenticación. Es la forma en que los equipos de identidad pasan de preguntar "¿tuvo éxito el inicio de sesión?" a "¿qué variante del viaje tomó este usuario, cuánto costó y cómo debería dirigirse de manera diferente la siguiente sesión?". Los equipos que construyen primero la capa de observabilidad y la capa de minería de procesos inmediatamente después, establecerán el punto de referencia para la categoría. Los equipos que se mantengan en las tasas de éxito agregado seguirán perdiendo de vista las variantes sistémicas subyacentes.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

FAQ#

¿Qué es la minería de procesos de autenticación?#

La minería de procesos de autenticación es la aplicación de técnicas de minería de procesos comerciales a los registros de eventos de inicio de sesión. Reconstruye el gráfico dirigido de eventos por sesión, compara el viaje de autenticación real con el diseñado y clasifica las variantes de desviación por frecuencia y costo. Se sitúa por encima de la observabilidad de autenticación y por debajo de la orquestación.

¿En qué se diferencia de los análisis de autenticación?#

Los análisis de autenticación reportan métricas como la tasa de éxito de inicio de sesión, la tasa de abandono y la tasa de uso de passkeys. La minería de procesos va más allá al reconstruir la secuencia completa de eventos por sesión y preguntar qué variantes del viaje existen, con qué frecuencia ocurre cada una y dónde difiere cada una de la ruta feliz diseñada. Los análisis informan resultados. La minería de procesos explica trayectorias.

¿Por qué la adopción de passkeys hace necesaria esta disciplina?#

Las implementaciones de passkeys son la primera razón por la que los equipos de CIAM instrumentan eventos del lado del cliente. Una vez que existen esos eventos, las métricas agregadas ocultan demasiado: una tasa de éxito del 92% puede enmascarar una tasa de abandono del 40% en la ruta de la passkey. La minería de procesos rechaza ese promedio y obliga a los equipos a observar las variantes por separado.

¿Cómo se conecta la minería de procesos con la autenticación step-up?#

La autenticación step-up funciona mejor cuando se basa en una calificación de riesgo en lugar de estar basada en reglas. La minería de procesos proporciona la evidencia a nivel de sesión (línea de base de cohorte, desviación de la ruta histórica del usuario, reputación del dispositivo) que permite que un motor de step-up tome una decisión detallada en lugar de una decisión contundente de un límite rígido.

¿Mi IDP ofrecerá esto de forma nativa?#

Poco probable a corto plazo. Los IDP optimizan el plano de control. La minería de procesos es una disciplina del plano de datos con un alto volumen de eventos y una alta cardinalidad en todas las combinaciones de SO, navegador y administrador de credenciales. El patrón coincide con lo que vemos hoy en la capa de SDK, cubierto en nuestra guía de compra frente a construcción.

¿Qué es lo primero que un equipo de CIAM debería medir?#

Comienza con la frecuencia de la variante en la ruta de la passkey: ¿qué porcentaje de sesiones siguen la ruta feliz y cuáles son las cinco principales variantes de desviación clasificadas por frecuencia? Ese único gráfico suele ser suficiente para revelar las dos o tres correcciones que impulsan más la adopción de passkeys en general.