🔐 OAuth Device Code Phishing：为什么“官方登录码”也会把账号送出去
很多人听到钓鱼，脑子里先想到假登录页。可 OAuth Device Code Phishing 更阴一点，它经常连密码都不直接偷。攻击者会先在真正的身份提供方发起一次设备授权流程，然后把那串看起来很正规的 code 和登录地址发给受害者，说“这是公司 VPN / Microsoft 365 / GitHub / 云平台的验证步骤，你去官方页面输入这串码就行”。受害者确实打开了真的官网，也确实把 code 输进了真的页面，于是心理防线会瞬间放松，觉得“我都在官方站点操作了，怎么会有问题”。
问题就出在这里。Device Code 本来是给电视、CLI、打印机这类不方便输入账号密码的设备准备的。设备先拿到一个 device_code 和 user_code，用户再去另一台设备上完成授权。攻击者如果先替你发起这个流程，他就已经拿着 device_code 在轮询了。你一旦在官方页面完成授权，令牌不是发到你手里，而是发给最初发起流程的那一端，也就是攻击者控制的客户端。整个过程里，用户没有把密码输进假站，却把“授权结果”亲手交了出去。
这类攻击现实里很容易成功，因为它利用的是人对“官方域名”和“验证码式操作”的天然信任。很多企业还把 MFA 当成护身符，但这招绕的不是密码强度，而是授权边界。只要你的账号被诱导去“批准一个本不该批准的客户端”，MFA 也可能只是帮攻击者完成了最后一道门禁。更糟的是，如果授权范围带有 Mail、Files、Graph API 或 repo 访问权，后果不是一次登录成功，而是持续性的 API 令牌滥用。
防它不能只喊“别点陌生链接”。真正有用的是把“谁发起授权”这件事钉死。企业侧要限制 Device Code Flow 的适用范围，能关就关，不能关就至少对高权限应用禁用；对 Entra ID、Google Workspace、GitHub OAuth 这类平台，要审计哪些应用能走设备授权，哪些租户允许用户自助同意。用户侧则要养成一个硬习惯：看到输入 code 的登录流程，不只看域名，还要看“你正在授权给谁”。如果页面上显示的应用名、发布者、权限范围和你当前要做的事对不上，立刻停。安全团队还应该监控异常的设备授权事件、短时间内的 consent 增长、来自不常见客户端 ID 的 token 签发，以及拿到令牌后立刻访问邮件或文件 API 的行为链。
🧪 你在公司 IM 里收到“IT 支持”消息，让你去
💡 核心记忆：设备码登录最危险的地方不是假官网，而是你在真官网上替攻击者完成了授权。
#Security
很多人听到钓鱼，脑子里先想到假登录页。可 OAuth Device Code Phishing 更阴一点，它经常连密码都不直接偷。攻击者会先在真正的身份提供方发起一次设备授权流程，然后把那串看起来很正规的 code 和登录地址发给受害者，说“这是公司 VPN / Microsoft 365 / GitHub / 云平台的验证步骤，你去官方页面输入这串码就行”。受害者确实打开了真的官网，也确实把 code 输进了真的页面，于是心理防线会瞬间放松，觉得“我都在官方站点操作了，怎么会有问题”。
问题就出在这里。Device Code 本来是给电视、CLI、打印机这类不方便输入账号密码的设备准备的。设备先拿到一个 device_code 和 user_code，用户再去另一台设备上完成授权。攻击者如果先替你发起这个流程，他就已经拿着 device_code 在轮询了。你一旦在官方页面完成授权，令牌不是发到你手里，而是发给最初发起流程的那一端，也就是攻击者控制的客户端。整个过程里，用户没有把密码输进假站，却把“授权结果”亲手交了出去。
这类攻击现实里很容易成功，因为它利用的是人对“官方域名”和“验证码式操作”的天然信任。很多企业还把 MFA 当成护身符，但这招绕的不是密码强度，而是授权边界。只要你的账号被诱导去“批准一个本不该批准的客户端”，MFA 也可能只是帮攻击者完成了最后一道门禁。更糟的是，如果授权范围带有 Mail、Files、Graph API 或 repo 访问权，后果不是一次登录成功，而是持续性的 API 令牌滥用。
防它不能只喊“别点陌生链接”。真正有用的是把“谁发起授权”这件事钉死。企业侧要限制 Device Code Flow 的适用范围，能关就关，不能关就至少对高权限应用禁用；对 Entra ID、Google Workspace、GitHub OAuth 这类平台，要审计哪些应用能走设备授权，哪些租户允许用户自助同意。用户侧则要养成一个硬习惯：看到输入 code 的登录流程，不只看域名，还要看“你正在授权给谁”。如果页面上显示的应用名、发布者、权限范围和你当前要做的事对不上，立刻停。安全团队还应该监控异常的设备授权事件、短时间内的 consent 增长、来自不常见客户端 ID 的 token 签发，以及拿到令牌后立刻访问邮件或文件 API 的行为链。
🧪 你在公司 IM 里收到“IT 支持”消息，让你去
microsoft.com/devicelogin 输入一串 8 位 code，说这是修复 Outlook 同步问题的标准流程。页面域名是真的，MFA 也正常弹出。这个场景里，最关键的风险信号是什么？ 💡 核心记忆：设备码登录最危险的地方不是假官网，而是你在真官网上替攻击者完成了授权。
#Security
