{"id":12681,"date":"2020-06-18T02:34:46","date_gmt":"2020-06-18T02:34:46","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/06\/18\/monitoring-applications-that-require-identity-management-authentication\/"},"modified":"2026-08-28T00:40:14","modified_gmt":"2026-08-28T00:40:14","slug":"monitoring-applications-that-require-identity-management-authentication","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/monitoring-applications-that-require-identity-management-authentication\/","title":{"rendered":"Monitoreo de aplicaciones que requieren autenticaci\u00f3n IAM"},"content":{"rendered":"
\"Illustraci\u00f3n
Detr\u00e1s de un inicio de sesi\u00f3n IAM, cada comprobaci\u00f3n tiene que recorrer el mismo camino que un usuario: app, proveedor de identidad, MFA y regreso.<\/figcaption><\/figure>\n

Su comprobaci\u00f3n de tiempo de actividad indica que la aplicaci\u00f3n est\u00e1 bien. Mientras tanto, nadie puede iniciar sesi\u00f3n, porque el proveedor de identidad que est\u00e1 delante de ella est\u00e1 agotando el tiempo. Para cualquier aplicaci\u00f3n detr\u00e1s de una autenticaci\u00f3n de Gesti\u00f3n de Identidad y Accesos (IAM), el inicio de sesi\u00f3n es parte del producto, y un monitor que se detiene en la pared de inicio de sesi\u00f3n est\u00e1 monitoreando lo incorrecto. La regla operativa: tratar la autenticaci\u00f3n como c\u00f3digo de aplicaci\u00f3n orientado al usuario, incluso cuando el IdP pertenece a un proveedor, porque los usuarios nunca experimentan “aplicaci\u00f3n activa, inicio de sesi\u00f3n ca\u00eddo” como una falla parcial; para ellos, el producto simplemente desaparece.<\/p>\n

Las aplicaciones autenticadas son el punto ciego cl\u00e1sico del monitoreo sint\u00e9tico. Una simple comprobaci\u00f3n HTTP obtiene un saludable 200 desde la p\u00e1gina p\u00fablica de inicio de sesi\u00f3n mientras la cadena de redirecci\u00f3n SSO, el desaf\u00edo MFA, o el intercambio de tokens detr\u00e1s de ella est\u00e1n rotos. La \u00fanica manera de ver lo que un usuario autenticado ve es guionando todo el flujo, credenciales, segundo factor y todo, y ejecutarlo seg\u00fan un horario.<\/p>\n

Eso plantea las preguntas que esta gu\u00eda responde: \u00bfc\u00f3mo guionas una cadena de redirecci\u00f3n SSO?, \u00bfqu\u00e9 haces con los c\u00f3digos MFA dise\u00f1ados para impedir la automatizaci\u00f3n?, \u00bfd\u00f3nde guardas las credenciales para que no se filtren?, y \u00bfc\u00f3mo sabes si un inicio de sesi\u00f3n lento es culpa de tu app o del proveedor de identidad?<\/p>\n

\u00bfQu\u00e9 es la Gesti\u00f3n de Identidad y Accesos (IAM)?<\/h2>\n

La Gesti\u00f3n de Identidad y Accesos es el marco de pol\u00edticas y servicios que decide qui\u00e9n puede acceder a qu\u00e9 recursos, y lo prueba al iniciar sesi\u00f3n. En la pr\u00e1ctica significa que un proveedor central de identidad (IdP), como Okta, Microsoft Entra ID, Auth0 o Ping, maneja la autenticaci\u00f3n para muchas aplicaciones a trav\u00e9s de inicio de sesi\u00f3n \u00fanico (SSO)<\/a>, usualmente sobre SAML o OpenID Connect, con autenticaci\u00f3n multifactor (MFA) superpuesta. Si quieres los mecanismos del protocolo en profundidad, consulta nuestra pieza complementaria sobre c\u00f3mo funciona la autenticaci\u00f3n en gesti\u00f3n de identidad<\/a>. Para prop\u00f3sitos de monitoreo, una propiedad importa m\u00e1s: el camino de inicio de sesi\u00f3n ahora cruza sistemas que no controlas completamente, y cada uno de ellos puede fallar independientemente de tu aplicaci\u00f3n.<\/p>\n

Por qu\u00e9 las Aplicaciones Autenticadas Son Dif\u00edciles de Monitorear<\/h2>\n

Cuatro cosas hacen que las aplicaciones protegidas por IAM sean m\u00e1s dif\u00edciles de monitorear que una p\u00e1gina p\u00fablica.<\/p>\n

La pared de inicio de sesi\u00f3n ciega las comprobaciones simples.<\/strong> Una comprobaci\u00f3n de disponibilidad HTTP solo puede confirmar que la p\u00e1gina de inicio de sesi\u00f3n se carga. Todo lo que los usuarios realmente pagan est\u00e1 detr\u00e1s de la autenticaci\u00f3n, por lo que una falla en el flujo de inicio de sesi\u00f3n o en la propia aplicaci\u00f3n es invisible hasta que alguien se queja.<\/p>\n

El flujo abarca m\u00faltiples partes.<\/strong> Un inicio de sesi\u00f3n toca tu aplicaci\u00f3n, tu IdP, el servicio MFA y a menudo un endpoint de tokens, cada uno en su propio dominio con su propia DNS, TLS e infraestructura. Tu aplicaci\u00f3n puede estar perfectamente saludable mientras una falla de un IdP externo bloquea a todos. El mismo problema de dependencia aparece en aplicaciones que usan SSO<\/a> en general.<\/p>\n

SSO es una cadena de redirecci\u00f3n, no una p\u00e1gina.<\/strong> Los flujos SAML y OAuth\/OIDC rebotan el navegador entre dos o tres dominios, intercambian aserciones o c\u00f3digos de autorizaci\u00f3n, y establecen cookies de sesi\u00f3n en el camino. Una herramienta a nivel de petici\u00f3n que no ejecuta JavaScript ni sigue redirecciones como un navegador real malreportar\u00e1 el flujo en cada salto.<\/p>\n

MFA existe para detener scripts.<\/strong> Los c\u00f3digos de un solo uso, avisos push y CAPTCHA son deliberadamente hostiles a la automatizaci\u00f3n. El monitoreo tiene que trabajar con el motor de pol\u00edticas del IdP, no contra \u00e9l, lo que requiere planificaci\u00f3n que una simple comprobaci\u00f3n de tiempo de actividad nunca necesit\u00f3.<\/p>\n

Mapa la Cadena de Redirecci\u00f3n SSO Antes de Guionarla<\/h2>\n

Antes de grabar nada, recorre el inicio de sesi\u00f3n una vez en un navegador con herramientas de desarrollador abiertas y anota cada salto. Un flujo t\u00edpico iniciado por SP se ve as\u00ed: el usuario solicita la aplicaci\u00f3n, es redirigido al IdP, se carga la p\u00e1gina de inicio de sesi\u00f3n del IdP, se env\u00edan las credenciales, aparece el desaf\u00edo MFA, el IdP publica una aserci\u00f3n SAML o devuelve un c\u00f3digo de autorizaci\u00f3n OAuth a tu URL de retorno, la aplicaci\u00f3n lo intercambia por una sesi\u00f3n y se carga la primera p\u00e1gina autenticada.<\/p>\n

\"Diagrama
Cada salto en la cadena SSO es un punto de fallo distinto, y cada uno merece su propio punto de control de monitoreo.<\/figcaption><\/figure>\n

Cada salto en esa cadena es un punto de fallo distinto: resoluci\u00f3n DNS para el dominio del IdP, certificado expirado en la URL de retorno, renderizado lento de la p\u00e1gina IdP, intercambio de token que agota el tiempo. Los saltos que anotes se convierten en los puntos de control de tu script y en los l\u00edmites donde querr\u00e1s divisiones de tiempos m\u00e1s tarde.<\/p>\n

Nota qu\u00e9 dominios son tuyos y cu\u00e1les pertenecen a un proveedor. Esa distinci\u00f3n es la que convierte una alerta en una decisi\u00f3n de enrutamiento: una falla en el dominio del IdP va al equipo de identidad o a la p\u00e1gina de estado del proveedor, una falla en la URL de retorno va a tu equipo de aplicaci\u00f3n. Si tu arquitectura tambi\u00e9n depende de OAuth para APIs, el endpoint de tokens merece su propia comprobaci\u00f3n a nivel de petici\u00f3n; consulta monitoreo de tokens JWT y endpoints de token OAuth<\/a> para saber c\u00f3mo observar directamente la emisi\u00f3n de tokens.<\/p>\n

El mapa de dominios tambi\u00e9n explica por qu\u00e9 la p\u00e1gina de estado del IdP no puede sustituir tu propio monitoreo. Un banner verde “Todos los Sistemas Operativos” significa que el servicio del proveedor est\u00e1 activo globalmente; no dice nada sobre la configuraci\u00f3n SAML de tu inquilino, el certificado en la URL de retorno o la ruta de red entre tus usuarios y su p\u00e1gina de inicio de sesi\u00f3n. El script de extremo a extremo es la \u00fanica comprobaci\u00f3n que responde la pregunta que tus usuarios realmente hacen.<\/p>\n

C\u00f3mo Guionizar un Flujo de Inicio de Sesi\u00f3n Autenticado, Paso a Paso<\/h2>\n

Paso 1: Crea una cuenta dedicada para monitoreo.<\/strong> Configura un usuario de prueba tipo servicio en tu IdP que exista solo para monitoreo: m\u00ednimo privilegio, sin acceso a datos reales de clientes y un nombre reconocible como svc-synthetic-monitor<\/code> para que sus inicios de sesi\u00f3n sean f\u00e1ciles de identificar en los registros de auditor\u00eda.<\/p>\n

Paso 2: Graba el inicio de sesi\u00f3n como una transacci\u00f3n multi-paso en navegador.<\/strong> Usa una herramienta de guionizaci\u00f3n con navegador real como EveryStep<\/a> para capturar la secuencia completa: abre la URL de la aplicaci\u00f3n, sigue la redirecci\u00f3n al IdP, ingresa credenciales, env\u00eda y aterriza en la p\u00e1gina autenticada. Un navegador real importa aqu\u00ed porque ejecuta JavaScript, sigue redirecciones entre dominios y carga cookies exactamente como lo hace el navegador de un usuario.<\/p>\n

Paso 3: Decide tu estrategia MFA antes de finalizar el script.<\/strong> Las opciones y sus compromisos est\u00e1n cubiertos en la siguiente secci\u00f3n. Escoge una deliberadamente; un script que funcione solo porque el MFA qued\u00f3 en cach\u00e9 fallar\u00e1 en un punto arbitrario despu\u00e9s.<\/p>\n

Paso 4: Asegura algo que solo un usuario autenticado pueda ver.<\/strong> Llegar a una URL no es prueba de inicio de sesi\u00f3n. Valida un elemento post-inicio de sesi\u00f3n, como el encabezado del panel o el nombre de pantalla de la cuenta, usando aseveraciones de contenido<\/a>. Muchos inicios de sesi\u00f3n fallidos aterrizan en una p\u00e1gina de error con estilo que devuelve HTTP 200, y solo una aseveraci\u00f3n lo detecta.<\/p>\n

Paso 5: Extiende el script un paso m\u00e1s all\u00e1 del inicio de sesi\u00f3n.<\/strong> Abre un registro, ejecuta una b\u00fasqueda, carga un informe. El \u00e9xito de autenticaci\u00f3n mientras la aplicaci\u00f3n detr\u00e1s est\u00e1 rota es un modo real de falla, y un paso extra lo cubre. La estructura es igual a cualquier script de monitoreo de transacciones web<\/a>: cada acci\u00f3n del usuario es un paso, y cada paso se mide.<\/p>\n

Paso 6: Establece umbrales y alertas por paso.<\/strong> Dale a cada paso su propio presupuesto de tiempo y conecta fallas a tus reglas de alerta<\/a>, para que un mensaje diga “paso MFA excedi\u00f3 umbral,” no solo “inicio de sesi\u00f3n lento.”<\/p>\n

Paso 7: Ejec\u00fatalo desde donde est\u00e1n tus usuarios.<\/strong> Ubicaciones externas para una aplicaci\u00f3n SaaS p\u00fablica; un agente privado dentro de tu red para aplicaciones internas cuyo IdP o capa de aplicaci\u00f3n no sea accesible desde internet p\u00fablico.<\/p>\n

Manejo de MFA y OTP en Scripts Sint\u00e9ticos<\/h2>\n

MFA es donde la mayor\u00eda de proyectos de monitoreo autenticado se estancan, porque el prop\u00f3sito del segundo factor es que solo una contrase\u00f1a, que es todo lo que un script tiene naturalmente, no basta. Hay cuatro estrategias viables, y la correcta depende de cu\u00e1nto del paso MFA necesitas ejercer versus cu\u00e1n estrictamente tu equipo de seguridad controla excepciones.<\/p>\n

\n\n\n\n\n\n\n\n\n
Estrategia<\/th>\nC\u00f3mo funciona<\/th>\nCompromiso<\/th>\nMejor ajuste<\/th>\n<\/tr>\n<\/thead>\n
Exenci\u00f3n de acceso condicional<\/td>\nLa pol\u00edtica del IdP omite MFA para la cuenta de prueba cuando se conecta desde IPs conocidas de monitoreo<\/td>\nEl paso MFA no se prueba; requiere un alcance estricto de IPs<\/td>\nEquipos cuyo IdP soporta pol\u00edticas basadas en red<\/td>\n<\/tr>\n
Semilla TOTP en el script<\/td>\nLa cuenta de prueba se inscribe en un autenticador; el script guarda la semilla en un vault y calcula el c\u00f3digo actual en tiempo de ejecuci\u00f3n<\/td>\nLa semilla es un secreto permanente que debe almacenarse en un vault y rotarse<\/td>\nEjecutar y temporizar completamente el paso real de MFA<\/td>\n<\/tr>\n
Recuperaci\u00f3n OTP por correo o SMS<\/td>\nEl script consulta un buz\u00f3n de prueba o un endpoint SMS por el c\u00f3digo de un solo uso y lo escribe<\/td>\nLento y dependiente de entrega, por lo que hay m\u00e1s falsos positivos<\/td>\nApps que solo ofrecen c\u00f3digos por correo o SMS<\/td>\n<\/tr>\n
Contrase\u00f1as de aplicaci\u00f3n \/ c\u00f3digos de bypass<\/td>\nUna credencial secundaria est\u00e1tica evita el desaf\u00edo interactivo<\/td>\nOpci\u00f3n m\u00e1s d\u00e9bil; muchos IdPs est\u00e1n elimin\u00e1ndolas<\/td>\nAplicaciones legadas sin mejor alternativa<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

El enfoque TOTP merece la opci\u00f3n predeterminada cuando tu IdP lo permite. Debido a que los c\u00f3digos basados en tiempo se generan desde una semilla compartida mediante un algoritmo documentado, un script puede producir un c\u00f3digo v\u00e1lido en tiempo de ejecuci\u00f3n y atravesar el desaf\u00edo real, lo que significa que el monitor mide el paso MFA en lugar de saltarlo. Para un recorrido detallado de ese patr\u00f3n, consulta c\u00f3mo monitorear aplicaciones web protegidas con OTP<\/a>.<\/p>\n

Cualquiera que elijas, delim\u00edtalo solo a la cuenta de monitoreo. Una exenci\u00f3n MFA o c\u00f3digo de bypass aplicado a m\u00e1s que un solo usuario de prueba con m\u00ednimos privilegios, restringido por IP de origen, convierte una conveniencia de monitoreo en una superficie de ataque. Tu equipo de seguridad deber\u00eda aprobar el mecanismo y la exenci\u00f3n deber\u00eda aparecer en sus revisiones de pol\u00edticas.<\/p>\n

Mantener Seguras las Credenciales de Monitoreo<\/h2>\n

Un monitor de inicio de sesi\u00f3n es un conjunto de credenciales v\u00e1lidas que se ejecuta seg\u00fan un horario, y debe tratarse con el mismo cuidado que cualquier otra credencial de servicio.<\/p>\n

Nunca uses la cuenta de una persona.<\/strong> Las cuentas reales exponen datos reales en capturas de pantalla y grabaciones, rompen el monitor con cada cambio de contrase\u00f1a y contaminan los registros de seguridad con actividad que nadie puede atribuir. La cuenta que crees debe pasar la pregunta del radio de impacto: si esta credencial se filtrara, \u00bfqu\u00e9 podr\u00eda alguien ver o cambiar antes de ser deshabilitada? La respuesta correcta es aburrida: sin roles administrativos, sin registros de clientes, sin capacidad para acu\u00f1ar tokens duraderos.<\/p>\n

Guarda los secretos en un vault.<\/strong> Contrase\u00f1as, semillas TOTP y secretos de cliente pertenecen a un almacenamiento cifrado que el script consultar\u00e1 en tiempo de ejecuci\u00f3n, como el Secure Vault<\/a> de Dotcom-Monitor, nunca en el texto del script, donde terminan en exportaciones, historial de versiones y pantallas compartidas. El enmascarado debe extenderse a registros, capturas de pantalla y grabaciones de video que produzca el monitor.<\/p>\n

R\u00f3talas seg\u00fan un horario y p\u00f3nlo en calendario.<\/strong> La rotaci\u00f3n de credenciales es una buena pr\u00e1ctica, y una contrase\u00f1a de cuenta de prueba expirada es tambi\u00e9n la fuente m\u00e1s com\u00fan de falsas alertas de inicio de sesi\u00f3n. Rota la entrada en el vault, no los scripts, as\u00ed una actualizaci\u00f3n se propaga a todos lados, y programa un recordatorio antes de cualquier pol\u00edtica de expiraci\u00f3n forzada que imponga tu IdP.<\/p>\n

Haz los inicios de sesi\u00f3n sint\u00e9ticos identificables.<\/strong> Una cuenta con nombre claro y IPs de origen conocidas permiten a tu equipo de seguridad distinguir el monitor de intentos de relleno de credenciales y excluir sus sesiones de an\u00e1lisis de producto para que no inflen n\u00fameros de uso.<\/p>\n

Expiraci\u00f3n de Sesi\u00f3n, Actualizaci\u00f3n de Token y L\u00f3gica de Re-Inicio de Sesi\u00f3n<\/h2>\n

Las sesiones son donde los monitores autenticados se deterioran en silencio. Dos comportamientos opuestos causan problemas: un monitor que reutiliza una sesi\u00f3n en cach\u00e9 deja de probar el inicio de sesi\u00f3n por completo y un monitor que hereda una sesi\u00f3n medio expirada falla de formas que la aplicaci\u00f3n nunca mostr\u00f3 a un usuario real.<\/p>\n

La regla que previene ambos: comienza cada ejecuci\u00f3n programada desde una sesi\u00f3n de navegador limpia<\/strong>, sin cookies ni tokens trasladados de la ejecuci\u00f3n anterior. Un inicio limpio fuerza la cadena completa de redirecci\u00f3n, env\u00edo de credenciales y MFA en cada ciclo, por lo que una falla del IdP aparece en la siguiente ejecuci\u00f3n en lugar de esconderse detr\u00e1s de una cookie a\u00fan v\u00e1lida.<\/p>\n

Vale la pena tambi\u00e9n probar la persistencia de sesi\u00f3n, pero deliberada y separadamente. Si tu aplicaci\u00f3n depende de la actualizaci\u00f3n silenciosa del token para mantener a los usuarios autenticados, crea una transacci\u00f3n m\u00e1s larga cuyos pasos posteriores se ejecuten despu\u00e9s de que el token de acceso haya expirado, y asegura que el usuario sigue autenticado al final. Una falla en la actualizaci\u00f3n se muestra cuando los usuarios son enviados de vuelta a la p\u00e1gina de inicio de sesi\u00f3n en medio de una tarea, que es exactamente el s\u00edntoma que reproduce este script.<\/p>\n

A nivel de API, la emisi\u00f3n de tokens se puede observar sin un navegador: una comprobaci\u00f3n a nivel de petici\u00f3n contra el endpoint de token OAuth verifica que los tokens son emitidos y aceptados en cada ciclo. El monitoreo de API OAuth<\/a> de Dotcom-Monitor maneja ese flujo y combina bien con el script a nivel de navegador, ya que juntos separan “el IdP no puede emitir tokens” de “la aplicaci\u00f3n no puede consumirlos”.<\/p>\n

Temporizaci\u00f3n Por Paso: D\u00f3nde un Flujo Autenticado Se Lentifica<\/h2>\n

“El inicio de sesi\u00f3n tom\u00f3 nueve segundos” no es accionable. \u00bfNueve segundos d\u00f3nde? Un flujo autenticado cruza al menos dos organizaciones, por eso el valor del monitor depende de dividir ese total en los l\u00edmites que mapeaste antes: redirecci\u00f3n inicial, renderizado de p\u00e1gina IdP, validaci\u00f3n de credenciales, desaf\u00edo MFA, intercambio de aserci\u00f3n o token y carga de la primera p\u00e1gina autenticada.<\/p>\n

Los pasos guiados por script en navegador te dan exactamente esa divisi\u00f3n, porque cada paso se mide independientemente y viene con su propia cascada de peticiones. Establece la l\u00ednea base del rango normal de cada paso en lugar de analizar corridas individuales y alerta cuando haya desviaciones a nivel de paso, para que una regresi\u00f3n en un salto destaque, incluso cuando el total de extremo a extremo parezca aceptable.<\/p>\n

La temporizaci\u00f3n por paso convierte una discusi\u00f3n en una decisi\u00f3n de enrutamiento. Si el renderizado de la p\u00e1gina IdP se duplic\u00f3, el ticket va al proveedor de identidad con las marcas de tiempo. Si la carga de la p\u00e1gina post-callback se duplic\u00f3, va a tu equipo de aplicaci\u00f3n. Sin la divisi\u00f3n, ambos equipos se apuntan unos a otros.<\/p><\/blockquote>\n

El enrutamiento se vuelve m\u00e1s preciso si cada paso lleva una etiqueta de propietario desde el d\u00eda que lo mapeaste: propiedad de app (URL de callback, creaci\u00f3n de sesi\u00f3n, primera p\u00e1gina autenticada), propiedad de IdP (renderizado p\u00e1gina de login, validaci\u00f3n de credenciales, intercambio de token), propiedad de pol\u00edtica (desaf\u00edo MFA, decisiones de acceso condicional, avisos de consentimiento) y propiedad de red (DNS, TLS, proxies, accesibilidad de agente privado). Una alerta que dice “el paso de pol\u00edtica cambi\u00f3” abre una entrega de incidentes en lugar de un debate en sala de guerra.<\/p>\n

Las l\u00edneas base a nivel de paso tambi\u00e9n detectan el modo de falla lenta que los chequeos binarios arriba\/abajo no captan: un servicio MFA que se desplaza de un segundo a cinco en un mes nunca dispara alerta, pero degrada cada inicio de sesi\u00f3n y es claramente visible en la tendencia de tiempos por paso. Observa el flujo de inicio de sesi\u00f3n igual que observar\u00edas cualquier p\u00e1gina de inicio de sesi\u00f3n<\/a>, luego deja que los datos por paso te indiquen qu\u00e9 lado del l\u00edmite SSO necesita atenci\u00f3n.<\/p>\n

La Conclusi\u00f3n<\/h2>\n

Monitorear una aplicaci\u00f3n protegida por IAM significa monitorear el camino de autenticaci\u00f3n como parte de la aplicaci\u00f3n, porque para tus usuarios as\u00ed es. La receta operativa: mapea la cadena de redirecci\u00f3n SSO, guioniza el inicio de sesi\u00f3n completo como una transacci\u00f3n multi-paso con navegador real bajo una cuenta dedicada con m\u00ednimo privilegio, maneja MFA deliberadamente con una exenci\u00f3n delimitada o una semilla TOTP en vault, guarda cada secreto en almacenamiento cifrado, comienza cada ejecuci\u00f3n desde una sesi\u00f3n limpia y divide tiempos en cada salto para que las fallas se dirijan al equipo correcto en la primera alerta.<\/p>\n

Haz eso, y la pared de inicio de sesi\u00f3n deja de ser un punto ciego. Sabr\u00e1s que el IdP est\u00e1 lento antes que el servicio de ayuda, sabr\u00e1s si una falla es tuya o del proveedor, y tendr\u00e1s el registro por paso para probar cualquiera de los casos.<\/p>\n

\n

Monitorea Detr\u00e1s de la Pared de Inicio de Sesi\u00f3n<\/h2>\n

Guioniza tu inicio de sesi\u00f3n SSO completo como una transacci\u00f3n de monitoreo sint\u00e9tico<\/a> con navegador real usando EveryStep, guarda las credenciales en vault y mide cada paso del flujo. Comienza una prueba gratuita<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

C\u00f3mo monitorear aplicaciones detr\u00e1s de inicios de sesi\u00f3n SSO y MFA: crear guiones de flujos autenticados, manejar OTP, asegurar credenciales y cronometrar cada paso.<\/p>\n","protected":false},"author":21,"featured_media":34487,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[875],"tags":[],"class_list":["post-12681","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12681","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=12681"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12681\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/34487"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=12681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=12681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=12681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}