🔐 Device Code Phishing：为什么“官方登录码”也能被钓鱼很多人对钓鱼的直觉还停留在“假登录页骗密码”，但现在更危险的一类攻击，恰恰不需要你把密码输进假网站。它利用的是 OAuth 2.0 Device Authorization Grant，也就是很多电视、游戏机、CLI 工具常见的“请在另一台设备输入 8 位验证码完成登录”。这套流程本来是给“输入能力差的设备”准备的，设计上没问题，问题出在攻击者可以把“真实平台生成的合法验证码”拿来骗你替他授权。
事情为什么会发生？因为用户看到的是正确域名、正确登录页、正确验证码，整套交互都像真的。攻击者先在目标平台上发起一次 device flow，拿到一个 user_code，然后把这个码通过邮件、IM、假工单、假客服消息发给你，说“你的账户异常，请立刻输入此验证码验证身份”。你一旦真的在官方页面输入并登录，平台会认为“这次授权已经得到用户同意”，接下来访问令牌会发给谁？不是发给你，而是发给最初发起 device flow 的那个客户端，也就是攻击者控制的程序。
这类攻击最麻烦的地方就在于，它不靠伪造页面，不靠键盘记录，甚至能绕过一部分“只认官方域名”的安全习惯。用户完成的是一次“真授权”，只是授权对象被偷换了。现实里它常见在 Microsoft 365、GitHub、云平台 CLI、企业 SSO 和各种支持“代码登录”的 SaaS 服务里，尤其适合被用在社工攻击里，因为它比“给我密码”更像正常操作。
防它不能只喊“别乱点链接”，那太空。关键是让用户在授权最后一步看清“你正在授权给谁”。如果页面显示的是陌生应用名、可疑权限范围，或者请求的是长期离线访问（offline_access）、读取邮箱、读取代码仓库、管理组织之类高权限，就该立刻停下。企业侧更实际的做法是限制 device flow 的适用范围，只允许受信客户端使用，给高风险 OAuth 授权加条件访问策略，监控异常的新应用同意记录，还要尽量关闭普通用户对第三方应用的自由授权能力。很多团队的坑在这里：MFA 做了，反钓鱼培训也做了，但 OAuth 同意界面没人管，于是账户还是被拿走。
🧪 你在公司 IM 里收到一条“IT 支持”消息：由于邮箱系统升级，请你访问
microsoft.com/devicelogin 并输入代码 F7K9-L2Q 完成验证。页面域名正确，登录后也没有报错。这个操作最核心的风险点是什么？
💡 核心记忆：看到“官方验证码登录”别只看网址，对安全来说更重要的是“我到底在授权给哪个应用、给了什么权限”。
