您的正常运行时间检查显示应用程序运行正常。与此同时，没有人能登录，因为位于其前端的身份提供商超时了。对于任何受身份和访问管理（IAM）认证保护的应用程序，登录是产品的一部分，而一个停在登录墙前的监控是在监控错误的内容。工作规则是：即使身份提供商属于供应商，也要将身份验证视为面向用户的应用代码，因为用户从不会把“应用正常，登录异常”视为部分故障——对他们来说，产品就像消失了一样。
经过身份验证的应用程序是经典的合成监控盲点。简单的HTTP检查虽然能从公共登录页面获得200响应，SSO重定向链、多因素认证（MFA）挑战或其背后的令牌交换却可能已损坏。唯一的方式是编写完整流程的脚本，包括凭证、第二因素等，按计划运行，以看到登录用户所见内容。
这就引出了本指南回答的问题：如何通过SSO重定向链编写脚本，如何处理专为打击自动化设计的MFA代码，凭证应存储在哪里以防泄露，以及如何判断登录缓慢是应用自身的问题还是身份提供商的问题？
什么是身份和访问管理（IAM）？
身份和访问管理是决定谁可以访问哪些资源并在登录时加以验证的一套策略和服务框架。实际上，这意味着一个集中式身份提供商（IdP），例如Okta、Microsoft Entra ID、Auth0或Ping，通过单点登录（SSO）为多个应用提供认证，通常基于SAML或OpenID Connect，并在其上叠加多因素认证（MFA）。如果您想深入了解协议机制，请参阅我们的配套文章身份管理认证工作原理。对于监控而言，最重要的是：登录路径现在跨越您无法完全控制的系统，每个系统都可能独立失败。
为什么经过认证的应用程序难以监控
有四点原因使得受IAM保护的应用程序比公共页面更难监控。
登录墙使简单检查失效。HTTP可用性检查只能确认登录页面是否呈现。用户实际使用的所有内容都隐藏在认证之后，因此登录流程或应用本身出现故障时，除非有人投诉，否则无法发现。
流程跨越多个参与方。单次登录会触及您的应用、身份提供商、多因素认证服务，通常还有令牌端点，每个都拥有自己域名、DNS、TLS和基础设施。您的应用可能完全正常，但第三方IdP故障却会导致所有用户被锁定。这个依赖问题同样见于依赖SSO的应用。
SSO是重定向链，而非单页。SAML和OAuth/OIDC流程会让浏览器跨越两个或三个域名，交换断言或授权码，并一路设置会话Cookie。不执行JavaScript且不跟随重定向的请求级工具会在每个跳转上错误报告流程。
MFA存在就是为了阻止脚本。一次性代码、推送确认和验证码故意抗拒自动化。监控必须与IdP的策略引擎协同工作，而非对抗，这就需要一定规划，而这在普通的正常运行时间检查中是多余的。
在编写脚本前先映射SSO重定向链
在开始录制之前，用带有开发者工具的浏览器走一遍登录流程，记录每个跳转。一条典型的服务提供商（SP）发起的流程如下：用户请求应用，跳转到IdP，IdP登录页面呈现，提交凭证，出现MFA挑战，IdP向回调URL提交SAML断言或返回OAuth授权码，应用用它换取会话，第一个认证页面加载。
链上的每个跳转都是一个独立的故障点：IdP域名的DNS解析，回调URL的证书过期，IdP页面加载缓慢，令牌交换超时。您记录的跳转将成为脚本的检查点，也是后续设置时间拆分的边界。
注意哪些域属于您，哪些属于供应商。这个区分决定了警报的路由：IdP域的故障交给身份团队或供应商状态页，回调域的故障交给您的应用团队。如果您的架构还依赖OAuth用于API访问，令牌端点应该有自己的请求级检查；请参见监控JWT令牌和OAuth令牌端点以了解如何直接监控令牌发行。
域映射也是为什么IdP状态页无法替代您自己的监控。一个绿色的“所有系统正常”横幅意味着供应商全局服务正常，但不代表您的租户SAML配置、回调URL上的证书或用户到登录页面的网络路径没问题。端到端脚本是唯一能回答用户真实提问的检查。
一步步教你编写认证登录流程脚本
步骤1：创建专门的监控账户。在您的IdP中设置一个仅用于监控的服务型测试用户：最低权限，不访问真实客户数据，且名称易于识别，如svc-synthetic-monitor，方便在审计日志中识别登录。
步骤2：将登录录制为多步骤浏览器事务。使用诸如EveryStep等真实浏览器脚本工具捕获整个流程：打开应用URL，跟随跳转到IdP，输入凭证，提交，然后到达认证页面。真实浏览器很重要，因为它能执行JavaScript、跟踪跨域重定向，且像用户的浏览器一样携带Cookie。
步骤3：在完成脚本前决定MFA策略。选项及权衡将在下一节讨论。要慎重选择；脚本若仅凭MFA缓存存活，后面某处会失败。
步骤4：断言只有登录用户才能看到的内容。仅访问URL并不等于登录。用内容断言验证登录后的元素，如仪表盘标题或账户显示名。很多失败登录虽然返回HTTP 200，但呈现的是样式化错误页，只有断言可捕捉。
步骤5：登录后延伸脚本操作。例如打开一条记录，执行搜索，加载报表。认证成功但应用异常是常见故障，额外步骤可覆盖。脚本结构同任何网页事务监控脚本：每个用户操作是一步，每步计时。
步骤6：为每步设置阈值和警报。给每步分配时间预算，连接至警报规则，确保信息具体到“多因素认证步骤超时”，而非笼统的“登录慢”。
步骤7：从用户所在地运行脚本。面向公共SaaS的选用外部监控节点；用于内部应用（其IdP或应用层外部不可访问）则部署私有代理在您网络内。
在合成脚本中处理MFA和OTP
MFA是多数认证监控项目陷入瓶颈的关键，因为二次认证的意义就在于单凭密码（脚本天然具有）不足以通过。针对这一点，有四种可行策略，选择取决于您对MFA步骤的完整执行需求与安全团队对例外控制的严格程度。
| 策略 | 工作原理 | 权衡 | 最佳适用 |
|---|---|---|---|
| 条件访问豁免 | IdP策略从已知监控IP签入时跳过测试账户的MFA | MFA步骤本身不被测试；需严格IP范围控制 | IdP支持基于网络策略的团队 |
| 脚本中存储TOTP种子 | 测试账户注册认证器，脚本将种子保存在保险库中，运行时计算当前代码 | 种子是长期秘密，需要保管和定期轮换 | 全面执行并计时真实MFA步骤 |
| 电子邮件或短信OTP接收 | 脚本轮询测试邮箱或短信端点获取一次性验证码并输入 | 速度慢且受发送影响，误报较多 | 仅提供邮件或短信验证码的应用 |
| 应用密码／旁路码 | 静态次级凭证绕过交互挑战 | 安全性最低，许多IdP正逐步淘汰 | 无更好选项的遗留应用 |
当您的IdP支持时，TOTP方案是默认选择。基于时间的代码由共享种子和公开算法生成，脚本能运行时生成有效代码，实现真正挑战，并由监控计时MFA步骤而非跳过。详情请参阅如何监控OTP保护的网页应用。
无论选择哪种策略，都要限定于监控账户。广泛应用MFA豁免或旁路码将监控便利变成攻击面。应由安全团队审核机制，且豁免应纳入策略审查流程。
保护监控凭证安全
登录监控器是一组有效凭证按计划执行，应与任何服务凭证同等谨慎对待。
切勿借用真人账户。真实账户截图和录制中暴露真实数据，密码变更时打断监控，还会污染安全日志，导致活动难以追责。您创建的账户应满足爆炸半径问题：如果凭证泄露，攻击者在禁用前能看见或修改什么？正确答案是无聊的——无管理员权限，无客户记录，无制造持久令牌的能力。
使用保险库存储秘密。密码、TOTP种子和客户端秘密应储存在加密的存储中，脚本在运行时引用，例如Dotcom-Monitor的安全保险库，而非硬编码在脚本文本中，否则它们会出现在导出、版本历史和共享屏幕中。对日志、截图和视频捕获也应做掩码处理。
按计划轮换并设定日历提醒。凭证轮换是良好习惯，测试账户密码过期是最常见的假登录报警源。轮换保险库中的条目而非脚本，这样一次更新能传播至所有地方，并提前设置IdP强制过期策略提示。
让合成登录易于识别。清晰命名的账户和已知IP让安全团队区别监控器和凭据填充攻击，且可排除监控会话对产品分析的影响，避免使用数据被虚增。
会话过期、令牌刷新与重新登录逻辑
会话是认证监控轻轻腐败之处。两种相反行为都会导致问题：复用缓存会话的监控器完全没验证登录，继承半过期会话的监控器会表现出用户未曾见过的应用故障。
防止两者的规则是：每次定时运行均从干净浏览器会话开始，不保留之前周期的Cookie或令牌。干净开始确保每次循环走完重定向链、凭证提交和MFA，让IdP故障能及时显现，而非隐藏在仍然有效的Cookie背后。
会话持久性也值得单独测试。如果应用依赖静默令牌刷新保持登录，构建更长的事务，让后期步骤在访问令牌生命周期结束后执行，并断言用户仍处于登录状态。刷新失败表现为用户操作中途被退回登录页，正是此脚本重现的症状。
在API层面，不依赖浏览器就能监控令牌发行：针对OAuth令牌端点的请求级检查验证令牌是否在每个周期被发放和认可。Dotcom-Monitor的OAuth API监控处理此流程，可与浏览器级脚本配合，二者合用能区分“IdP无法发令牌”和“应用无法使用令牌”。
每步计时：认证流程在哪些环节变慢
“登录用了九秒”没可操作价值。九秒花在哪？认证流程跨越至少两家组织，监控价值在于将总时长按先前映射的边界拆分：初始重定向、IdP页面加载、凭证验证、多因素挑战、断言或令牌交换、首个认证页面加载。
脚本化浏览器步骤恰好提供这种拆分，因为每步单独计时，并附带请求瀑布图。应基于每步的正常波动范围建立基线，非只看单次，且在步骤级别监控偏差，确保某个跳转延迟变大时即使端到端总时长仍可接受，也能及时发现。
每步计时能将争议变为路由决策。若IdP页面加载时间加倍，带时间戳的工单应提交给身份供应商。若回调后页面加载加倍，交由您的应用团队处理。无拆分时双方只会互相推诿。
更精准的路由依赖于您首次映射时就给每步贴上所有者标签：应用所有（回调URL，会话创建，首个认证页）、IdP所有（登录页加载，凭证验证，令牌交换）、策略所有（MFA挑战、条件访问决策、同意提示）和网络所有（DNS、TLS、代理、私有代理的可达性）。警报若写着“策略所有步骤变更”，启动的是事件交接而非战情室辩论。
步骤级基线还能捕捉单纯上下线检测完全漏掉的渐进变慢故障模式：如某MFA服务从1秒退化到5秒，整月无故障警报，但每次登录都变慢，且步骤时长趋势线中清晰可见。用和监控登录页相同的方式监控登录流程，再借助步骤级数据判断SSO边界哪一方需要关注。
总结
监控受IAM保护的应用就意味着将认证路径作为应用一部分来监控，因为对用户来说就是如此。有效方案是：映射SSO重定向链，使用专门的最低权限账户，将完整登录编写成多步骤真实浏览器事务脚本，有计划地处理MFA（使用限定豁免或保险库中存储的TOTP种子），将所有秘密保存在加密存储中，每次运行从干净会话开始，且在每个跳点拆分计时，确保首次警报时故障能直接路由至正确团队。
如此，登录墙不再是盲点。您会比帮助台更早发现IdP缓慢，明确是自身还是供应商故障，并拥有每步记录为证。
监控登录墙后的系统
使用EveryStep将完整SSO登录流程脚本化为真实浏览器合成监控事务，将凭证存入保险库，并计时操作流程的每一步。免费试用。
