OAuth授权钓鱼攻击如何绕过多因素认证防护

防钓鱼认证体系经过多年发展与严格审查，已形成成熟的安全框架。然而，在授权层面，企业安全在很大程度上仍依赖于用户的“信任点击”行为。要真正弥合这一安全缺口，我们必须以管理身份认证的同等标准——即同等级别的可见性、持续监控与即时撤销能力——来审视并管理OAuth授权与AI Agent连接。

2026年2月，一个名为EvilTokens的钓鱼即服务平台开始活跃。仅五周内，它就成功入侵了五个国家超过340家微软365企业用户。其攻击手法极为隐蔽：受害者会收到一条消息，引导他们前往合法的 microsoft.com/devicelogin 页面输入一个短代码，并完成常规的多因素认证。用户误以为这是一次普通的登录流程，殊不知，他们亲手向攻击者递交了能够长期访问其企业邮箱、云存储、日历及联系人数据的有效刷新令牌。更严峻的是，这些令牌的有效期取决于企业的租户策略，可能长达数周甚至数月，远超单次会话时间。

整个过程堪称“静默入侵”：攻击者无需窃取密码，不会触发额外的MFA提示，甚至在标准的登录日志中都不会留下明显的异常记录。攻击成功的核心原因在于，OAuth授权同意界面已像过去的Cookie横幅一样，成为用户习惯性点击的对象。而现有的反钓鱼与身份安全机制，却普遍忽视了对这一关键授权层的监控。安全研究人员将这种新型威胁称为“授权钓鱼”或“OAuth钓鱼攻击”。过去十年，一次成功的钓鱼攻击可能仅泄露密码；如今，它直接交出了长期有效的刷新令牌，而且这种攻击就发生在大多数企业视为核心安全防线的身份控制体系之内。

为何MFA无法识别OAuth授权

传统的凭证钓鱼攻击，需要攻击者重放窃取的用户名和密码，而现代身份验证体系通常会在重放时要求第二因素验证。即便是通过中间人攻击获取的会话Cookie，也会被安全信息和事件管理（SIEM）系统结合地理位置、设备指纹和行为模式进行分析，从而暴露异常。

图1：凭证钓鱼会留下SIEM可关联的登录痕迹

但OAuth授权走的完全是另一条路径。用户是在合法的身份提供商（如微软）域名下完成认证，通过了正规的MFA验证，然后才点击了“接受”授权按钮。攻击者最终获取的令牌，是整个OAuth流程正常运作的产物——由身份提供商合法签发、限定于用户同意的范围、并且具备刷新能力。MFA在此完全失效，因为MFA验证在用户点击“接受”授权之前就已经成功完成了。

图2：OAuth授权不会留下重放痕迹，仅产生可刷新令牌

另一个严峻的安全挑战是刷新令牌极大地延长了攻击者驻留时间。EvilTokens分发的令牌，即使用户事后修改了密码，依然保持有效。其有效期从数周到数月不等，完全取决于企业租户的OAuth策略配置。这意味着，仅靠修改密码无法切断攻击者的访问，只有显式地撤销授权，或者配置了要求重新授权的条件访问策略，才能真正终止风险。

授权常态化的演变过程

实际上，这种攻击向量自OAuth协议标准化以来就一直存在。真正变化的是它赖以生存的生态环境。如今，用户点击授权界面的频率，已经堪比当年习惯性点击“接受所有Cookie”横幅。每一次安装AI助手、集成新的SaaS生产力工具、添加涉及企业账户的浏览器扩展，都会触发一次OAuth授权请求。现代知识工作者每月接触的合法授权请求数量，早已远超OAuth威胁模型最初设计时的预期。

不仅如此，授权范围的描述也常常采用模糊或弱化风险的表述。“读取邮件”听起来权限有限，但实际上它可能涵盖用户可访问的所有邮件、附件及共享线程；“在您不在场时访问文件”则意味着签发的长期令牌在用户想要撤销时可能无法立即生效。授权描述与实际权限之间的这种信息落差，恰恰为攻击者提供了操作空间。

应用所有者视野下的毒性组合

单个OAuth授权或许只让攻击者获得某个特定应用的有限权限，但真正的企业安全风险往往隐藏在多个权限的交叉组合之中。例如：一位财务人员授权了AI会议摘要工具访问其日历和邮箱，又授权了生产力助手访问公司共享云盘，同时还授权了CRM增强工具连接客户数据库。每一个授权都单独经过了审批，但没有任何一个应用的所有者批准过这种“权限组合套餐”。此时，风险面已经扩展为三个权限通过同一用户身份交叉关联。一旦那个会议摘要工具被攻陷，攻击者就能通过同一个用户身份，横向移动并触及敏感的合同草案和客户记录。

这种“毒性组合”的本质，是权限被分解到了多个应用中，再通过OAuth授权、SaaS集成或AI Agent桥接起来，形成了一个没有任何单一应用所有者会将其视为独立风险面的复杂访问关系图。由于桥接关系存在于所有应用之外，单个应用的审计日志根本无法察觉这种横向移动。

图3：两个SaaS应用间未经共同批准的毒性组合

无论是安装一个模型上下文协议（MCP）服务器、点击一次OAuth授权，还是同意一个浏览器扩展的权限请求——每一个新的连接桥接都诞生于一次看似无害的点击。MCP服务器正在成为新一代的OAuth式攻击面，它允许AI Agent通过授权界面现有的“一次性信任”机制获取限定权限。2025年的Salesloft-Drift安全事件就展示了这种攻击规模化的后果：一个遭入侵的下游连接器，通过客户合法批准的OAuth令牌，将影响扩散到了700多个Salesforce租户。每一个客户都授权了集成，但没有人批准过这种级联效应。

关键检查项清单

要弥合这个安全缺口，就必须将OAuth授权与AI Agent连接纳入现有的身份安全与访问管理（IAM）体系进行统一治理。以下检查项可以帮助企业安全团队揭示真实的风险暴露点：

然而，纯流程管控存在其局限性。这些危险的桥接关系存在于没有单一应用“拥有”的动态关系图中，并且其创建速度可以像一次MCP安装或OAuth点击一样快。要实现持续的风险监控，就需要一个能够专门针对这种运行时身份与权限关系层进行观察的安全平台。

AI安全平台的应对之道

新一代的云安全与身份安全平台正在尝试自动化处理大多数此类问题。它们能够实时地将每一个OAuth授权、AI Agent和第三方集成映射到动态的身份关系图谱中，而不是被动地等待下一次审计。这些平台持续展示着应用间的桥接关系、闲置的令牌以及偏离安全策略的行为。

以Reco平台为例，它将AI Agent安全、身份治理和威胁检测整合到了一个统一的控制平面。其核心的“身份知识图谱”将人类与非人类身份，关联到他们在SaaS环境中实际可以访问的应用、OAuth授权和集成。

图4：Reco平台展示的AI Agent OAuth授权及关联账户

该平台能够实时发现新增的AI Agent和OAuth授权，将每一个权限范围映射回批准者的身份，监控行为偏差，并允许在令牌级别（而非笼统的账户级别）精确撤销访问。这为安全团队提供了信任关系实际如何形成的运行时层可见性，而不仅仅是事后的静态快照。

授权钓鱼可能不会长期处于企业安全视野的边缘。防钓鱼认证已获多年投入和审查，而授权层仍主要依赖用户信任。弥合这一缺口，意味着我们必须以对待身份认证的同等重视程度，运用全面的可见性、持续的监控和精准的撤销机制来严格管理OAuth授权与AI Agent连接。